Open access peer-reviewed chapter
Abstract
Customers are demanding services using evolving technologies, and firms need agility in the way systems are designed and delivered to quickly meet customer expectations. Such agility is in fact an organizational capability where a combination of internal and supplier/partner resources allow firms to quickly create customer value propositions and deliver value through digital services, that is, services using advanced digitization. Leadership that enables such a customer-centric and service-driven culture using technology is referred to as digital leadership. This chapter develops a 10-step methodology not only to show how an innovative value proposition moves from conception to implementation using an agile system and business architecture, but also to lead to the next set of innovations for review. This methodology, developed over four years iteratively using over 100 graduate student projects, is briefly illustrated through two case examples.
Keywords
- digital leadership
- system architecture
- business architecture
- agility
- organizational capability
- digital services
1. Introduction
Business transformation in an evolving digital environment calls on firms to operate at two different speeds [1]. Firms must continue to operate at the traditional speed to meet their established business market needs, while using a faster speed to explore new opportunities enabled by advanced digitization. When operating at a faster speed, firms must use entrepreneurial thinking to generate innovative ideas that create value for customers, design digital or IT-enabled services quickly using advanced technologies, and build organizational capability to deliver such services to meet customer expectations. Faster design and delivery of these digital services requires agility within the IT system and business architectures under the co-leadership of IT and business executives. This is in essence the definition of
Information technology and business leaders working together to build an agile system and business architecture is not a new phenomenon. Agility through modular software design was a critical feature of system architecture when the business focus was on seeking operational process efficiencies through digitization in the late 1970s and 1980s. The design, development, and subsequent maintenance of modular software systems has enabled “system-level” agility.
With the introduction of personal computers in the 1980s, the focus of agility became critical in the development of systems that support business decision-making. Managers were able to evaluate alternative scenarios with varying assumptions to address decision uncertainty using modularization of data, decision models (algorithmic and heuristic), and configurable user interfaces. The design of such user-driven and IT-enabled modular decision support systems enabled “decision-level” agility.
When markets demanded operational efficiencies and effectiveness to address external stakeholder expectations (e.g. faster responses to customer order fulfillment and better off supply chain management) in the 1990s, agility to share data and integrate processes across departmental boundaries became critical. The modular design of processes across the enterprise, using best practices and enterprise software, provided organizations with “process-level” agility.
With Internet and web-based technologies extending business processes into customer and supplier operations in the early twenty-first century, organizations needed agility to build better relationships with customers (e.g. tracking orders and addressing design flaws or service complaints) and suppliers (e.g. gaining access to inventories and addressing supply chain disruptions). By separating business policies or decision rules sensitive to environmental changes from the rest of business operations using customer relationship and supply chain management systems, organizations were able to build “business-level” agility.
In summary, organizations over the last four decades have used modularity in software, decisions, processes, and policies/business rules to build agility to address changing market conditions. Today, customers are demanding value creation at each of their interfaces with the organization (i.e. service encounters), face-to-face or virtual, as they make decisions related to the purchase of a product or service. Organizations therefore need modularity at the service encounter level so that they can adapt the business to changing customer expectations. In other words, organizations need the capacity to build “service-level” agility to address customer value creation through advanced digitization.
The agility built at the software, decision, process, and policy levels to meet customer needs is defined with an internal focus, that is, how best to structure an organization to deliver the final product or service. Service-level agility, however, requires an external and a much more granular focus, especially in a virtual environment where customers engage in their decision-making process. Each of their service encounters—as they search, review, and evaluate products before they decide to purchase, and as they address all their service needs post purchase—become critical to gain customer loyalty. Such service-level agility calls on an organization to build its capability to adapt quickly and even reconfigure its customer value proposition as customer expectations change. Any change in their expectations can cause customers to shift allegiance and move to a competitor. This makes successful completion of each service encounter (i.e. a micro-service or business) a critical organizational capability, with all such micro-services or businesses leading to the customer ultimately purchasing a product. One characteristic of this capability is the ability to mix and match organizational resources, internal and partner, to keep customers successfully engaged [2]. This chapter discusses how service-level agility can be proactively supported using a modular system and business architectures with a 10-step structured methodology.
2. A methodology to build agility in systems and business architecture
The growing use of mobile communication, social media, and the Internet is empowering customers to seek information, evaluate competitive products and services, and shift allegiances among competing firms to maximize their value. Firms have been using artifacts such as an “innovation sandbox” to allow employees, partners, and customers to develop innovative product/service ideas, and to use focused organizational resources to assess their commercial viability [3]. Such an entrepreneurial mindset often calls on a firm to “pilot test” ideas with customers before institutionalizing them as a part of the firm’s regular business model. However, firms today have to move beyond the “pilot test” approach and use a sustained two-speed approach to support business agility. The two-speed approach calls for use of a “faster speed” to continually look for innovative value propositions to support the current business model or create new business models, or both. The sustained use of a “faster speed” requires agility in both system and business architectures to realign organizational resources for the design and delivery of digital services.
IT and business leaders need and entrepreneurial mindset today to develop the digital quotient [4] or organizational capability to take advantage of advanced digitization opportunities and build a high performing digital enterprise [5]. McKinsey proposes six building blocks for creating a digital enterprise:
This chapter proposes a structured approach to build agility in the design and delivery of digital services. The 10-step methodology, shown in Figure 1, uses five distinct “service-level” components that create and sustain value throughout the design and delivery process.
Service innovation and delivery (steps 1 and 10): Develop innovative customer value propositions, often co-created with customer engagement, which are reviewed/refined after implementation to sustain innovation.
Service operations (steps 2 and 3): Identify customer service encounters that incrementally and collectively influence customer engagement in value creation, and map these encounters to specific processes/work-flows that will operationalize these service encounters.
Digital service design (steps 4 and 5): Leverage advanced technology to automate select processes/work-flows to develop digital services, and build a data warehouse to analyze value created and delivered and gain keen insight into customer decision processes.
Service strategy (steps 6 and 7): Strategically position digital services to address a customer’s competitive strategy.
Service management (steps 8 and 9): Structure the management team that includes both internal employees and external suppliers/partners to deliver digital services for customer use while mitigating customer risks.
Figure 1.
Digital leadership: customer centric, service driven and agility focused.
The customer focus is at the center of each of these service components. The service operations will meet evolving customer value propositions, and digital services designed will support customer engagement. The service strategy positions digital services to meet customer strategy, and service management ensures that a team of internal and external partners will deliver digital services to mitigate customer risk. In addition, as discussed earlier, service level agility is supported at each service encounter with modular system (service operations and digital service design) and business architecture (service strategy and management) to address changes in customer expectations or technologies all through the customer engagement in the purchase, design, and delivery process. This methodology is
2.1. Research methodology
The methodology proposed and used in teaching digital leadership is based on a combination of inductive and project-based learning.
In 2014, a course called “IT-Enabled Innovation” was taught to graduate students that focused on how innovations supported by advanced digitization require changes to business processes and organizational capability. Twenty-one projects by a mix of full-time and working professionals led to the first change in the methodology.
In 2015, an IT-enabled innovation was taught to 60 graduate students in France and the US, as they completed 21 projects, with half of the projects applied to real-world context. A balance scorecard was used that allowed innovation to be viewed as a by-product of a firm finding an opportunity to create customer value and studying its impact on a firm’s financial performance, business processes, and people. Feedback from this experience led to the next change.
In 2016, digital innovation to create customer value was viewed from two different and yet interdependent perspectives: technology that designs a “service” to create this value and business strategy (in all its forms: marketing, finance, operations, etc.) that delivers this value. This approach was used by 76 graduate students in France and the US in 30 different projects, with over half of the projects applied to a real-world context. Feedback from this experience finally led to the 10-step methodology discussed earlier.
In 2017, this method was used by 26 graduate, 80 under-graduate and 14 executive MBA students in the US in 39 projects, half from real-world businesses, to further improve the methodology.
As new technologies continue to transform the way organizations (commercial, non-profit, and governmental) service their customers in all the roles they play as consumers, patients, citizens, members, and so on, some of the nuances of various steps used in the methodology will continue to be refined (e.g. how to position a service and how to mitigate risks). The next section discusses two example cases that describe this methodology.
3. Illustration of the methodology
Two example cases that provide a high-level summary of this methodology came out of the author’s five-year experience in applying some of these concepts in the health care field. The health care industry is going through a significant transformation since patients have begun using advanced technologies such as the Internet, smart phones, wireless technologies, and social media to seek information and self-manage their health conditions. Hospitals in the US have also had to adapt to some of the reimbursement changes introduced by the Affordable Care Act (ACA)—with increased focus on improving patient satisfaction, reducing patient readmission, and providing sustained care under accountable care models. Continuity of care after discharge of patients from the hospitals has become essential to helping patients self-manage their health and allowing post-discharge care providers (e.g. pharmacies and rehab centers) to interact with patients and physicians in monitoring patients remotely when needed. Technologies that have shown some success inside a patient room in a hospital can be extended and integrated with systems in these external care facilities as well as “wearable technologies.” This section illustrates the methodology in two cases: one at a pharmacy and the other within a patient room, with potential use at extended care facilities.
A smart phone that seniors can use to order prescriptions and have them delivered to their home—Prescription@Home
An integrated patient room technology (referred to as a “patient room robot”) that can support a number of patient room activities often supported by disparate technologies such as “call bells” (to communicate with nurses), EMR (to remind nurses on medication administration and moving patients for specific lab tests), and other hospital systems (to connect patients with food service and nurses)—Robot@Hospital
3.1. Prescription@Home
Patients traditionally take their prescriptions to drugstores to have them filled by pharmacists. A pharmacist has discovered that several patients are older citizens who are often unable to come to the pharmacy to pick up their prescriptions for many reasons.
Consultations with older patients, physicians, and family members led the pharmacist to explore the design of a digital service (a mobile or a web-based app). This service will allow a senior and/or his family to submit their prescriptions online and have these delivered to their home. Let us refer to this digital service as Prescription@Home.
To support this service, the pharmacy should determine various customer touchpoints or service encounters. Each encounter by itself is crucial to ensure continued patient engagement and satisfaction with the pharmacy. With digital services supported remotely by apps, patients can easily move from one app to another when there are service response difficulties. For these reasons, each service encounter is evaluated using specific metrics to ensure it meets customer needs. For Prescription@Home, Figure 2 shows the service encounters and metrics.
Figure 2.
Patient encounter with pharmacy and metrics.
Fulfilling each service encounter requires that the pharmacy design a set of processes and define workflows that move work and/or information among these processes to complete the service encounter. Each service encounter may require multiple additional interactions with the customer to accomplish the goal. For example, the “collect prescription” service encounter may be slightly different for a patient requesting a refill than for a new patient, when a patient may have to provide both a patient profile and the new prescription. For the three service encounters at Prescription@Home, Figure 3 shows the processes/work-flows, along with the interactions with any external partners (e.g. physicians, insurance firms, etc.).
Figure 3.
Service encounters with processes and workflows.
While the goal of digital services is to automate all the processes/workflows that support a service encounter, automation is not a prerequisite. Digitization may not support some processes/workflows (e.g. fill prescription). Therefore, the goal in this step is to decide on the type of digitization that will meet the customer’s value proposition, fully realizing that there is a cost and complexity associated with each digitization. Some of these digitization opportunities may use established technologies such as access to databases and online communication, while others may use newer technologies such as sensors or mobile-based interfaces. Figure 4 shows the digitization proposed for processes/workflows associated with Prescription@Home.
Figure 4.
Digitization strategies for Prescription@Home digital service (in italics).
One of the expected outcomes of automation is the generation of data that is not only used to support faster communication among various processes and customer interactions (operational support), but is also used to help analyze the data against the targets associated with the service metrics (e.g. 99.99% accuracy of payment recording, 95% delivery of prescriptions within two days, etc.). In addition, the pharmacy may want to gather information about customer service encounters and demographic data to better segment the patients, alter service delivery times, or improve service innovations for the future.
The data gathered may be stored using relational database or other database architectures, and multiple data analytic techniques can help the organization gain insight into the decision process of customers. For Prescription@Home, Figure 5 shows the data model used to store relevant prescription and other information needed for performance evaluation. The data items shown in blue help gain insight into patient and physician behavior, and the red data items help assess pharmacy performance against its stated metrics. The rest of the items shown in black helps support pharmacy operations.
Figure 5.
Data warehouse to support Prescription@Home services here.
Data analyzed from patients will not only help evaluate service delivery effectiveness but also address potential segmentation of customers to create additional value. In addition, the services can support select patient populations either in whole or in part, and select services can help individual patients or pharmacies. For example, Prescription@Home, in various forms, can support individual patients, nursing homes, or even physicians and nurse managers who want to provide prescriptions at their facilities. Some seniors can benefit from all services, while others may need only a few services (e.g. all but the payment option). In addition, a large pharmacy may use the new digital service to expand its reach into new markets, while another pharmacy may see it as deepening its service to its current patient market.
The service delivered to the individual patient or pharmacy is intended to support their competitive strategy—either cost reducing or value differentiating. Depending on the focus, one can position the service differently. Such flexibility in positioning a digital service to address differences in strategy is important to sustain competitiveness. In the example, some large pharmacies may view Prescription@Home as supporting differentiation, while others see it as supporting cost-reduction. Some individual seniors may see it as convenience (value-based differentiation), while others see it as reducing cost (e.g. gas expense) and saving time.
The delivery of digital services to meet patient expectations rapidly will require a team of internal staff and external suppliers/partners with skills and experience that match the patient’s or pharmacy’s ability to adopt and implement these services. In addition, the newness of technology embedded in the digital service and the maturity of technology at the patient’s home or at the pharmacy call for varying degrees of business skills and technical maturity on the part of the team delivering this service. In the Prescription@Home example, the service delivery team may combine internal pharmacy and data analytics experience with external supplier/partner skills to collect payments and distribute prescriptions. The delivery team skills may also vary depending on the customer: pharmacy or a senior living at home.
The number of digital services using advanced digitization technologies, the significant gathering and use of sensitive customer data, and the use of new technology partners all contribute to risk, even if they all help support faster design and delivery of such services. These risks are classified as operational, technical, compliance, and strategic and can address patient or pharmacy risks. For Prescription@Home, the firm delivering the digital service may use established partners (e.g. PayPal or FedEx) to mitigate payment processing and distribution risks initially, use multiple layers of control to mitigate patient data risk, and use established technologies and larger pharmacies to deliver services in the early stage to mitigate operational and technical risk.
For Prescription@Home, the implementation strategy may use early adopters and less complex operations (e.g. refills) to build momentum for further implementation of other services. The implementation will not only address value propositions as promised to a patient or a pharmacy, but will also track expectation gaps in service design and delivery, leading to the identification of new opportunities for innovation. This becomes especially critical when digital services support multiple patient populations. Some of these gaps may also lead to identifying complementary services that can help seniors who still want to come to the pharmacy to pick up their prescription, but just want the convenience of ordering them from home.
In summary, we have discussed how the structured methodology proposed in this chapter is used to build agility in the way a digital service is designed (i.e. system architecture) and delivered for patients and pharmacies (i.e. business architecture). In this example, the service encounters are offered in sequence to complete the value proposition (collect and deliver a prescription at home). The next example illustrates how the digital services can be designed and delivered for service encounters that are relatively independent and yet offered as a mix to meet the needs of a particular customer segment.
3.2. Robot@Hospital
Within a hospital, a nurse needs to attend to many demands, such as dressing a patient’s sores, administering medications, or preparing patients to be ready for transportation to labs for tests. These demands may limit the ability of a nurse to give personalized attention to a patient, and the challenge is one of empowering patients to seek assistance from something like a patient room robot. A personalized robot can tell a patient to wait for services when a nurse is busy, tell staff to wash their hands, provide educational material to a patient on treatment procedures, among others. Technologically speaking, a robot can make a “smart bed” talk to a nurse when a patient is trying to get up from the bed, remind the nurse about insulin when a diabetic patient is ready to consume food, and remind a nurse about a pain medication schedule that should be administered.
Such robotic services may not all exist today, but laboratories and companies are developing interactive robotic application and service platforms to address patient service needs [6, 7, 8]. The goal is to make robotic technology in whatever form (e.g. either as a “mobile robot in the image of a person” or simply an iPad with relevant apps) a platform to support the integration of communication and interaction among a number of caregivers and patients, even if what exists today is rather sparse [9]. We will illustrate the use of the digital leadership methodology discussed here by looking at how one might go about designing and delivering robotic services in a patient room.
3.2.1. Innovation
Many technologies are already being used in hospitals today, such as electronic badges for tracking care delivery staff, real time locator tags for tracking patient flow in the hospital, and distinct patient call buttons to request specific services (pain, bathroom support, etc.) [10]. They have become a way for patient-care delivery staff to communicate and deliver value to the patient. The discussion below provides the service system architecture used to design a patient room robot that is agile to address patient service needs. It is a combination of Steps 2–5.
3.2.2. Service system architecture
3.2.2.1. Services
We focus on four patient-care services: provide general non-clinical support, cater food, manage pain, and support patient lab visits. The primary customers for all these services are patients in a hospital room waiting for care or post-treatment during recovery and prior to discharge. The digitization of each patient service request, if handled by a nurse, can lead to too many alerts and contribute to stress (referred to as technostress [11]). While a robot can help reduce such stress, for the discussion here we will limit ourselves to value propositions that focus on patient support.
3.2.2.2. Processes/workflows
The first step in supporting each service encounter is to identify the processes/workflows used to operationalize this service. Figure 6 identifies four service encounters and the associated processes/workflows that need execution. Note that EMR is a digital technology currently used to perform the processes in support of some of the service encounters.
Figure 6.
Patient services and process/work-flows.
3.2.2.3. Digitization
Figure 7 shows how the robot alters the processes/workflows. Here, the robot provides an integration of several of these workflows. For example, in support of lab transport, the robot monitors the electronic medical records, confirms with the lab, schedules an appointment, and communicates to all the staff. To build flexibility, the role of the robot is unbundled or subdivided into individual digital modules, so they can change if the technology or patient requirements change. For example, communicating with the lab staff is an individual module and implemented as an email, a text alert, or even a phone message. Similarly, if an organization does not have transport staff and lab staff brings the transport to pick up the patient, then this module becomes unnecessary.
Figure 7.
Digitization of processes/work-flows using patient room robot.
3.2.2.4. Data warehouse
The data for lab services include data related to diagnosis and tests extracted from electronic medical records, specific patient room transaction data (such as patient call data related to tests and lab tests data), staff contact to communicate information, calendar data to schedule tests, and so on. In addition to this operational data, the data needed to support performance evaluation includes time to fulfill a request related to the transportation of a patient to the lab, the response time of the nurse to a patient call request, the number of lab services performed, patient satisfaction, and responsiveness. Besides this performance data, one may collect other information that will help gain deeper insight into services requested by the patient (e.g. the type of tests performed and when they are performed, where they stayed in the hospital and when (before or after a major procedure), patient demographics, and the frequency of lab requests, etc.). Figure 8 provides an overview of the service architecture to support one service (lab tests).
Figure 8.
System architecture for service 4.
3.2.3. Business architecture
3.2.3.1. Positioning
The envisioned robotic services can help a hospital address different patient needs, such as providing these services to only certain rooms with critically ill patients and offering a select set of these services to skilled nursing facilities or patient homes post discharge. The flexibility of the service architecture can thus help a hospital look at its patient population and associated services and deliver them selectively to meet market needs.
3.2.3.2. Strategy
The robot will help a hospital’s need for focused cost leadership. One of the unique characteristics of a digital business is the intermediate value generated by the data it creates. The data generated from the patient segments by a hospital can help it tailor its services effectively and alter room assignments and staff allocation and extend some of these services (e.g. diabetic support and lab support) post discharge. This can be useful for hospitals that want to use robotic services for value-based differentiation. In addition, the digital service provider and/or hospital can use the aggregated data to benchmark services that can reduce hospital costs, develop medical protocols for tests on patients with certain diagnoses, influence patient satisfaction at a hospital, and extend services to patients at home or at a nursing home. Some of these analyses can be a part of premium services for hospitals seeking a differentiation strategy or lead to the development of an entirely new market (e.g. nursing homes). In other words, the modularity in service design can help position the digital services to support either a cost leadership or a differentiation strategy.
3.2.3.3. Structure and partnerships
The patient room robot is an integrating device and needs access to communication protocols and data from a number of digital partners. For example, the robot needs a connection to a hospital’s EMR and lab management, as well as staff scheduling systems (for scheduling transport staff). In addition, the robot has to connect to the nurse call systems that enable patient–nurse communication. By acting as an intermediary between the patient and the nurse, it can reduce the number of alerts using additional intelligence. Each technology vendor partnership has a differing impact on the success of implementation. In addition, the team involved in the design and delivery of the service has to be flexible to adapt to the culture and focus of the hospital, as well as the way the robot supports hospital strategy. In other words, the structure of the team involved in design and delivery, with various vendors/partners, has to be flexible as the positioning and strategy of the robot changes in responds to patient demands.
3.2.3.4. Risk mitigation
Agility to integrate digital services to meet changing hospital expectations on pricing, delivery, support, and so on, and work with partners (internal and at the customer site) to address technology and integration challenges all require an internal workforce that is adaptive and an organizational governance that is effective. Several issues surface when the robot supports patient room operations. These include: Is there the right talent to design and deliver the services? Do the roles and responsibilities of the people involved reflect the changing market? Is there adequate security to address compliance needs? Is the technology sufficiently mature and risk free to develop the product and integrate it at the customer site? The operational risks (including talent-related challenges), technical risks (including both vendor and cyber security challenges), compliance risks (including governance and regulatory challenges), and strategic risk (including financial, reputational, and even partnership challenges [12, 13] have to be addressed using appropriate risk mitigation strategies.
3.2.3.5. Implementation
One way to mitigate some of these risks is to develop an implementation strategy that aligns with the speed with which a hospital wants to realize the value from a patient robot. Some of the implementation options here include: introducing the patient robot into a few rooms at first, integrating the robotic services to a few hospital technologies (e.g. EMR, lab management, and catering) to reduce technical risk, or offer services incrementally. In addition, the degree of stakeholder commitment to adopt robotic services may also dictate the order of implementation of these robotic services (lab tests, pain management, or dietary services).
Value propositions developed in support of patients will continue to change, and not all of them require the same type of services. For example, services needed for a cancer patient will be different from services needed for a patient who underwent a heart by-pass surgery. Technologies to detect bacteria in shoes worn by family members or staff entering a room may not be available today, but they could be useful in the future. Some patients may need a version of a patient room robot when they leave the hospital for select services (e.g. prescription reminders, follow-up physician appointments, diets, etc.). In the long run, the scope and scale of opportunities for service robots for patients will continue to increase. Patient rooms may exist not just in a hospital but also in other places such as nursing homes, individual homes, and so on. A patient may want certain services offered digitally, and some can be non-health related. Some of the services may be relevant even if a customer is not a patient by definition (e.g. people physically challenged).
In summary, both examples illustrate how an agile system and business architecture can help a hospital or pharmacy continually look for innovative opportunities to create value for its patients and use the digital leadership methodology to quickly design and deliver digital services that generate this value.
4. Conclusions
The pace of change has increased since the beginning of the twenty-first century, with the rapid introduction of advanced information technologies (e.g. Internet/Web, mobile devices, wireless communication, and Internet of Things (IoT), among others) that enabled businesses to bring customer purchasing decision-making into the business value chain. To track customer experiences and address their evolving purchasing behaviors, many new companies have entered the marketplace, with some dis-intermediating brick-and-mortar companies and others acting as intermediaries of information aggregation and analysis. The net result of all these marketplace changes, in less than two decades, has made competing effectively quite complex.
Organizations in general are now forced to operate at two different speeds to address this complex market dynamic. The faster speed is to explore new opportunities and address threats posed by advanced digitization to their current business using innovative new products/services, and the regular speed is to continue to run the current business and adapt it to changes brought about from new products/service explorations to sustain growth. Digital leadership is an “enabling” leadership that supports continual exploration within an organization to create value for customers using advanced digitization. The digitization efforts start with a focus on creating value for customers (“customer centric”) using a service lens (i.e. how does digitization lead to improved services for the customer?). These digital services are then quickly designed to help improve customer interaction, engagement, and experience, and brought into the market to create value. Such a digital leadership methodology needs a close partnership of both IT and business leaders, each driven by the customer’s needs and expectations.
References
- 1.
Bossert O, Laartz J, Ramsey TJ. Running your company at two different speeds. McKinsey Quarterly. December 2014. p. 12-14 - 2.
Lusch RF, Nambisan S. Service innovation: A service-dominant logic perspective. MIS Quarterly. 2015; 39 (1):155-175 - 3.
Westerman G, Curley M. Building IT enabled innovation capabilities at Intel. MIS Quarterly Executive. 2008; 7 (1):08-33 - 4.
Catlin T, Scanlan J, Willmott P. Raising your digital quotient. McKinsey Quarterly. June 2015. p. 30-43 - 5.
Desmet D, Duncan E, Scanlan J, Singer M. Six building blocks for creating a high-performing digital enterprise. NY: McKinsey & Company; September 2015 - 6.
Bemelmans R, Gelderblom GJ, Jonker P, De Witte L. Socially assistive robots in elderly care: A systematic review into effects and effectiveness. Journal of the American Medical Directors Association. 2012; 13 :114-120. e111 - 7.
Galinato J, Montie M, Patak L, Titler M. Perspectives of nurses and patients on call light technology. Computers Informatics Nursing. 2015; 33 :359-367 - 8.
Kang JW, Hong HS, Kim BS, Chung MJ. Work assistive mobile robots assisting the disabled in a real manufacturing environment. International Journal of Assistive Robotics and Mechatronics. 2007; 8 :11-18 - 9.
Moustris G, Hiridis S, Deliparaschos K, Konstantinidis K. Evolution of autonomous and semi-autonomous robotic surgical systems: A review of the literature. The International Journal of Medical Robotics and Computer Assisted Surgery. 2011; 7 :375-392 - 10.
Klemets J, Evjemo TE. Technology-mediated awareness: Facilitating the handling of (un) wanted interruptions in a hospital setting. International Journal of Medical Informatics. 2014; 83 :670-682 - 11.
Khuntia J, Tanniru M, Weiner J. Juggling digitization and technostress: The case of alert Fatigues in the patient care system implementation. Health Policy and Technology Online. 2015; 4 :364-377 - 12.
Nissen V, Marekfia W. The development of a data-centred conceptual reference model for strategic GRC-management. Journal of Service Science and Management. 2014; 7 :63 - 13.
Sambamurthy V, Zmud RW. Arrangements for information technology governance: A theory of multiple contingencies. MIS Quarterly. 1999: 23 (2):261-290