At any given time, a business owner must be able to get an overview of what a service costs, which factors influence the cost, and its contribution to profits. Naturally, this general guideline also applies to the health care industry. But this is easier said than done. Even just the number of installed systems — ranging from the hospital information system (HIS) and entry of services rendered, to the management information system (MIS) and analysis — and frequent release upgrades of individual system components leave managers struggling to keep up.
One thing is certain for many health care IT managers: cost pressure remains, and with it the necessity of designing IT structures more efficiently than in the past. One key lies in formulating a stringent release strategy, which should include organizational, business, and technical questions:
- How can a release upgrade enable us to achieve our strategic goals better?
- What costs does the company incur during the release upgrade?
- Who is incurring the costs?
- Which provider will provide the company the greatest degree of planning reliability?
Definitely a Difficult Situation
Providers of a software solution check individual components at regular intervals, adapt them to current technological and legal standards, and then make the result available to users. Management in the user environment then has the choice of directly accepting the improvements provided by the release upgrade or waiting for future developments. Maneuvering room for making this decision becomes ever tighter as the expiration date of the software provider’s maintenance contract for the original version draws nearer.
It’s a complex issue because decision-making criteria for or against a new release must be oriented to the company’s strategic objectives. In contrast to companies in other industries, a hospital’s objectives are not defined by management alone. A variety of bodies — such as agencies, governments, and associations — exert an influence. For example, hospitals receive the better part of investment funds from the legal jurisdiction in which they’re located. This dependency makes it difficult to define company objectives.
Different Starting Points
In addition to these environmental factors, starting points vary widely from one company to the next. Users who have recently implemented a solution will probably find that the current version meets their needs in the immediate future. Moreover, in this case the introduction of the system is not yet complete, since fellow users are still required to cope with its learning curve. Budgets generally don’t provide sufficient supplementary funding for training on a new release, or for additional hardware components.
However, if a company has been running its business system for some time, managers likely hope for new features that will improve existing processes. In this situation, a release upgrade should be considered in light of the company’s business goals. This assessment can be difficult, particularly if the company lacks consistent business structures. For example, this could be the case if — after a change of carrier — a hospital is merged into another group or if isolated solutions have been developed over many years. In both cases, the result is a heterogeneous system environment.
Avoiding In-House Customization
When numerous components from different manufacturers are involved, it becomes more difficult for management to make a decision because it is confronted with the phenomenon of in-house customization, a direct consequence of the heterogeneous system environment. This refers to the numerous possible adaptations, enhancements, and constraints that go along with a release upgrade. When modifications to the system environment are performed independently, under time pressure, and with a crowbar approach to adapt individual system components to one another, technical problems down the road are pre-programmed, in the truest sense of the term. Also, from a cost perspective the actual task — the upgrade — recedes into the background compared to the customization work. The solution lies in ending heterogeneity and choosing a provider that will maintain the stability of core functions.
SAP R/3 Enterprise is such an application. The software is comprised of the SAP R/3 Enterprise Core and SAP R/3 Enterprise Extensions. Upgrading the SAP R/3 Enterprise Extensions does not affect the SAP R/3 Enterprise Core in any way. Users can deploy new functions in the extensions as desired. Extensions for additional functions in the future are implemented by upgrading the SAP R/3 Enterprise Extensions, while the SAP R/3 Enterprise Core remains unaffected. This encapsulated approach enables the user to respond to upgrades more flexibly. With SAP R/3 Enterprise, a company can at any time extend its system in specific areas that are relevant for its business processes, without compromising the stability of the application core.
Release Strategy as Part of Planning
Determining a release strategy is a key factor on the way to more efficient IT, and thus an important aspect of business planning. A release strategy is proactive and considers related issues. For example, if the manufacturer announces a limited period for maintenance on a release, or if the legal requirements change, these factors cannot be ignored.
Based on the pre-determined release strategy, the company’s IT objectives can be refined, measures and funds can be applied in a timely manner, and control mechanisms can be optimized. When formulating a release strategy, the consequences of a heterogeneous system environment quickly become apparent and encourage managers to work toward standardization. On the way to consistent IT structures, a solution should be applied that provides a stable basis for increased planning reliability.
These examples demonstrate — even for the seemingly simple issue of a release upgrade — how important it is to conduct an interdisciplinary exchange at management level. Due to the consequences and complexity of IT systems, the decision for or against a release upgrade must be a top priority. Furthermore, with regard to these decisions, it’s necessary to communicate with departments and coordinate the assignment of responsibilities. Insufficient coordination, or simply delegating all work to the IT manager, will lead to contradictory decisions and actions.