Download to read offline
More Related Content
Similar to Hi600 u07_inst_slides
More from ljmcneill33
Hi600 u07_inst_slides
- 1. HI-600: Analysis andDesign of Health Information Systems Design: Part I System Acquisition Strategies
- 2. TRANSITION FROM ANALYSISTO DESIGN ANALYSIS DESIGN What are the business needs? How do we build it? Business requirements System Requirements Logical process and data models Physical process and data models
- 3. Activities of theDesign Phase
- 4. SYSTEM ACQUISITION STRATEGIES •Custom Development • Packaged Software • Outsourcing
- 5. Custom Development PROS • Flexibleand creative development • Utilize current technologies • Improve skills and knowledge of own IT • Cheaper to develop and maintain CONS • Dedicated, time demanding effort • Requires high skilled IS professionals • Higher risk • Can cost more than expected
- 6. Packaged Software PROS • Testedand packaged • Faster implementation • Proven performance on core processes • Standardization • Existing user base and expertise CONS • Addresses only common needs • May require custom add-on (workaround) • Systems integration is challenging • Usually expensive • Long-term commitment
- 7. Outsourcing PROS • Low costof entry • Short setup time • Reduced cost of IT staff and infrastructure CONS • Compromising confidential information • Losing control over future development • Losing important skills of in-house professionals • Application Service Provider (ASP) • Software as a Service (SaaS)
- 8. Outsourcing Contract Types •Time and Arrangements • Fixed-price contract • Value-added contract
- 9. INFLUENCES ON THEACQUISTION STRATEGY
- 10. SELECTING AN ACQUISITIONSTRATEGY • More information gathering • Sources – Own IT – Vendors • Approaches – Request For Proposal (RFP) – Request For Information (RFI) – Request For Quote (RFQ) • Merging of analysis results into a matrix of alternatives and criteria
- 11. Developing an AlternativeMatrix Sample Alternative Matrix Using Weights
- 12. Purchasing vs. Custom •Uniqueness of the system need • Cost and Resources • Maintenance • Future business states and agility / scalability that will need to be built in • General advise • General needs: Purchase; Specific needs: Custom • RFP from vendors and from own IT • Consider hybrid
Editor's Notes
- #2 Last week, we concluded the Analysis Phase and this week, we are starting the Design Phase. At the end of the analysis phase, the final deliverable was a system proposal, which included Revised requirements definition statement Use cases Logical Process model (DFDs) Logical Data model (ERDs) Revised feasibility analysis and work plan Today, we will start with discussing how we transition from analysis phase to design phase, - which describes how the new system will operate, - develops the system requirements that describe details for building the system, - and produces the system specifications deliverable. As we start discussing the Design Phase, we will first talk about three alternative strategies to acquire a system; namely, custom development, packaged software, and outsourcing. We will also discuss what influences the decision on the acquisition strategies. This decision is a very high-impact decision, as it would be very difficult and costly to change the system acquisition strategy, once it starts to get implemented. Finally, we will cover what is involved in selecting an acquisition strategy, including how to develop an alternative matrix.
- #3 * The purpose of the analysis phase was to figure out what the business needs are. The purpose of the design phase, however, is to decide how to build a system that meets those needs. * During the initial part of design, the business requirements are converted into system requirements that describe the technical details for how to build the system. * Then, the logical process and data models are converted into physical process and data models. And finally, the deliverables of the design phase are communicated through a collection of design documents (including architecture, interface, programming, and data storage design specifications) and the physical process and data models; all combined into the system specification.
- #4 The very first task of the design phase is to determine a strategy for system acquisition. Here we decide whether we should build it in-house, buy it as a package, or outsource it to a consulting or development company. At the end of this process, we come up with an alternative matrix that helps us decide which strategy to choose. We will see the details of this process in a few moments, but let’s go through the other activities of the design phase first. Next week, we will learn how to design the architecture of the system and prepare hardware and software specifications. That will follow the user interface design. After that, we will tackle how to convert the logical process model (DFDs) of the analysis phase into physical process model and come up with program design specifications And finally, we will learn how to convert the logical data model (ERDs) of the analysis phase into physical data model, revise CRUD matrix to ensure the balance between process and data models, and come up with data storage design specifications. At the end of the design phase, the final deliverable called system specification is created, by combining all of the design phase deliverables we have just mentioned and presented to the approval committee for the final approval before implementation.
- #5 So let’s start with the three primary ways to approach the creation of a new system: 1. Develop a custom application in-house. 2. Buy a packaged system and (possibly) customize it; and 3. Rely on an external vendor, developer, or service provider to build or provide the system. Let us go through the advantages and disadvantages of each approach, then we will talk about how we can go about deciding which one to choose.
- #6 Custom development is building a new system in house from scratch. Pros of custom development: - It allows developers to be flexible and creative in the way they solve business problems. It can be highly specialized and customized according to the process or business needs of the organization. It is flexible or agile enough to adapt to regulatory changes or mandates such as “meaningful use” or ICD-9 to ICD-10 conversion. It also allows immediate implementation of user feedback rather than waiting years for a release from a vendor - Custom development allows to take advantage of the current technologies that can support strategic efforts of the organization. Whereas packaged software is usually slow to adapt to new technology standards (XML, Service-Oriented Architecture (SOA)) - Choosing this strategy also helps build technical skills and functional knowledge of the IS personnel within the organization. and helps strengthen the relationship between the IT department and clinical staff. - It can also be relatively inexpensive to develop and maintain, if the required skill set already exists within the organization Cons of custom development: - It requires a dedicated effort that include long hours and hard work. - It demands a variety of skills, but high skilled Information Systems professionals are difficult to hire and retain. Required skill set should be carefully identified and analyzed to see whether the skills exist within the organization or should additional or replacement personnel be hired? - The risks associated with building a system from the ground up can be quite high. Since your development team is the only experts on the new system, loosing crucial members of the team present a high-risk. There exists relatively few checks and balances and minimal oversight. For example, it is hard to judge whether the right technology for the system is being used or just the technology the team is more comfortable with. - It can also get expensive in the long run and IS staff can be tied to a particular system full time, jeopardizing other systems in the organization.
- #7 An alternative is to buy packaged software that has been written for common business needs. Packaged software can range from small single-function tools to huge all-encompassing systems such as ERP (enterprise resource planning) applications. The advantages of the packaged software include - It being much more efficient to buy programs that have already been created and tested. - A packaged system can also be bought and installed quickly compared with a custom system. - Typically, packaged software systems are very good at building a system around general processes and general workflows. - The choices are usually limited, therefore they create a form of standardization in the industry. - Also, with the packaged software, usually there exists an existing user base to gain insight from. And there exists a proven expertise and documentation that is available via consulting or the vendor. - One of the problems of packaged software is that companies utilizing packaged software must accept the functionality that is provided by the system with limited customization. Each organization’s workflow is different. So, it needs to be evaluated whether the packaged software will fit the organization’s needs out of the box. - A custom-built add-on program that interfaces with the packaged application, called a workaround, may be required to handle special needs of the organization. - Also, with packaged software Systems Integration is very challenging. Systems integration refers to the process of building new systems by combining packaged software, existing legacy systems, and new software written to integrate them. The key challenge in systems integration is finding ways to integrate the data produced by the different packages and legacy systems. On the other hand, for many packaged software, integration is typically built in with HL7 engines and parsers. - Packaged software are often prohibitively expensive Not only the initial cost of purchase, but also the continuous licensing and support fees should be carefully considered. - An to me the worst part of the packaged software is that, once it is bought, organizations are often stuck with the product for a very long time. There are many issues that need to be carefully considered. As sales people usually over commit the product’s capabilities, before the purchase all functionalities should be tested at a fully functioning implementation. Reputation of the vendor should also be examined to see - how well they respond to the customer requests, - whether the product gets updates to be compatible with future regulations, - and what process do they have in place for change control, etc..
- #8 Other than these two options of make or buy, there is also the outsourcing option Outsourcing means hiring an external vendor, developer, or service provider to create or supply the system. Outsourcing firms called application service providers (ASPs) that supply software applications and/or services. Software as a service (SaaS) is an extension of the ASP model. Among its advantages, it is worth to mention that it has a relatively lower cost of entry and a short setup time. It also helps reduce cost of IT staff and IT infrastructure. Some of the risks of outsourcing that should be considered include Possibility of compromising confidential information Losing control over future development compared to custom development And again compared to custom development losing important skills of in-house Information Systems professionals. The textbook nicely summarizes some guidelines for outsourcing in Figure 7-4. a couple that worth mentioning are: - ensuring that you never outsource what you don’t understand. - and choosing a stable outsourcing firm with a proven track record.
- #9 Without spending time on it, I will just mention that there are three types of outsourcing contracts: - Time and arrangements: pay for whatever time and expenses are needed to get the job done. - Fixed-price contract: you agree on a fix price for the entire project and the outsourcer absorbs the costs of overrun projects. - Value-added contract: the outsourcer reaps some percentage of the completed system’s benefits. Each of the contract types have advantages and disadvantages based on the project considered. However, managing outsourcer is an important task and should be assigned to a full-time person to protect the organization’s investment.
- #10 Now that we have an understanding of the choices of strategies for system acquisition, let us now look at what characteristics of the project would influence this choice: Business need If the business need for the system is common and the technical solutions already exist, packaged software is a better solution. On the other hand, when the business need is unique, a custom solution should be explored. Outsourcing is used in situations where the business need is not a critical element of company strategy. In-house experience If in-house experience exists for all the functional and technical needs of the system, it will be easier to build a custom application. However, a packaged system may be a better alternative for companies that have only the functional skills, but do not have the technical skills to build the desired system. And if neither functional nor technical experience exists within the organization, then outsourcing is a better option. Project skills If it is strategically important for the organization to build in-house technical or functional skills that are applied during project development, than it is better to custom build the system, so that the staff improve their skill set and the organization utilizes the acquired skills of its personnel. Project Management Custom applications require excellent project management and a proven methodology. There are so many things that can push a project off track, such as funding obstacles, staffing issues, and overly demanding business users. The project team should choose to develop a custom application only if it is certain that the underlying coordination and control mechanisms will be in place. Packaged and outsourcing alternatives also must be managed; however, they are more shielded from internal obstacles. Time Frame If time is limited, then the project team should probably start looking for a system that is already built and tested. If a custom alternative is chosen, and the time frame is very short, techniques like time-boxing should be used to manage the problem. Depending on the project, an outsourcing solution could take as long a custom development initiative.
- #11 So, we know what strategies available for system acquisition and which characteristics of the project influence the decision making process, let us see what it takes to arrive at a decision. To implement the strategies, we need more information such as: - What tools and technologies are needed for a custom development project? - What vendors make products that address the project needs? - What service providers would be able to build this application if outsourced? This type of information may be obtained from various sources ranging from the IS department, to system users, to companies that need similar systems, or the vendors. One helpful tool is the request for proposal (RFP), a document that solicits a formal proposal from a potential vendor, developer, or service provider. RFPs describe in detail the system or service that is needed, and the vendor respond by describing in detail how they could supply those needs. For smaller projects with smaller budgets, a shorter and less detailed request for information (RFI) may be sufficient. When a list of equipment is so complete that the vendor needs only provide a price and no additional detail, then a request for quote (RFQ) can be used. The second tool we can use is called an Alternative Matrix that merges the results of the analysis for system acquisition strategy selection into a matrix of alternatives and criteria.
- #12 The alternative matrix combines several feasibility analyses into one matrix. It contains technical, economical and organizational feasibilities for each system candidate, pros and cons of each, and other information. The matrix is a grid with alternatives across the top and different criteria along the side. Sometimes, weights and scores are added to create a weighted alternative matrix. The scores assigned here are subjective, so in order to avoid a biased analysis, it is better for each analyst to develop ratings independently.
- #13 So to summarize, some of the considerations in deciding which system acquisition strategy to choose include to answer How unique the process that we are trying to build a system around is How the product will evolve after implementation and how the regulation changes will affect the system How much each option costs and how does existing resources compare to demands of each option Whether the vendor provides support or the IT staff maintain the system and if IT will maintain it, whether enough resources and whether its staff will need additional training Whether the vendor is stable and reputable Are future upgrades covered in the maintenance agreement Whether the vendor has adequate staffing to support the system or additional outsourcing will be necessary So in closing, a few general advise from my experience that should be taken cautiously would include: Go with a vendor for general needs, such an EHR or Rx system. And seek customization for specialized one-off needs. But also consider hybrid opportunities And when dealing with a vendor, always make sure to know what to ask in the selection process by creating a detailed request for proposal and also have your own IT submit an RFP as well. So, that is it for this week. I hope you guys have a great week and I wish you all good luck with the exams.