3 Enterprise system complexity

In this chapter

This chapter provides an introduction to the issues that can arise when implementing and managing large-scale enterprise and healthcare applications. These issues may not be fully appreciated by readers who do not have direct experience with system integration and implementation. The research indicates that workarounds in both systems are a result of a mismatch between the ambitions of the organisation and the ability of employees to make effective use of the systems on a day-by-day basis. Among the challenges faced by employees in making use of enterprise applications are system accessibility and being able to adapt to accommodate neurodiversity.

————

Fitness to purpose

When I was working at Logica (a highly successful UK computer systems development consultancy) in the late 1980s there was a very strong emphasis on delivering solutions that were fit for purpose rather than fit to specification, even if this meant difficult discussions with the client and potentially having to undertake work that could not be billed to the client. The view was taken that client satisfaction was everything and that future business would make up for any short-term reduction in profits.

The core issue was that the specification developed by the client often turned out to be very wide of the mark, especially when it came to defining tasks and processes. Only when the system had been installed and pilot acceptance testing had begun did issues arise from the way that employees used workarounds to improve aspects of task completion that had not surfaced in the initial business process analysis and specification development. It was often the case that workarounds were then devised to ensure that acceptance of the pilot could be achieved but these turned out not to scale when the full implementation was put into operation.

At this point it is important to reflect on what constitutes an enterprise application (EA). These are applications which are in principle available to any employee across the organisation and are managed by the corporate IT department. An individual employee may only have partial access to the application, using certain features that have been deemed appropriate for their role and responsibilities. They are very unlikely to be aware of the full functionality of the application. Much of the research into enterprise application implementation has been on Enterprise Resource Planning (ERP) applications as these tend to be the core platform for an organisation, usually integrating with a range of other more specialised applications. In a hospital the Electronic Health Record (EHR) application would fulfil the same core purpose.

Putting the enterprise into the enterprise system

In 1998 the American information management consultant Tom Davenport wrote a seminal article in Harvard Business Review in which he questioned whether ERP systems were actually mirroring internal processes or was the reality that the processes were being adapted to be able to be implemented with the ERP.

Davenport comments

“In addition to having important strategic implications, enterprise systems also have a direct, and often paradoxical, impact on a company’s organization and culture. On the one hand, by providing universal, real-time access to operating and financial data, the systems allow companies to streamline their management structures, creating flatter, more flexible, and more democratic organizations.

On the other hand, they also involve the centralization of control over information and the standardization of processes, which are qualities more consistent with hierarchical, command-and-control organizations with uniform cultures….. Some executives, particularly those in fast-growing high-tech companies, have used enterprise systems to inject more discipline into their organizations. They see the systems as a lever for exerting more management control and imposing more-uniform processes on freewheeling, highly entrepreneurial cultures.”

He concludes

“Many chief executives, however, continue to view the installation of an ES as primarily a technological challenge. They push responsibility for it down to their information technology departments. Because of an ES’s profound business implications—and, in particular, the risk that the technology itself might undermine a company’s strategy—off-loading responsibility to technologists is particularly dangerous. Only a general manager is equipped to act as the mediator between the imperatives of the technology and the imperatives of the business. If the development of an enterprise system is not carefully controlled by management, management may soon find itself under the control of the system.”

The evidence from the research literature, and from stories in the news about failures of IT systems, is that these lessons have still not been learned.

The quest for productivity

The majority of enterprise system vendors sell on the promise that adopting their application will enhance productivity. At the same time the CIO is under pressure to improve the productivity of the workforce. A perfect fit? Productivity is a good metric for machines but a very poor metric for employees, especially those engaged in what might be termed knowledge work. It is a metric for outputs and not a metric for outcomes. Quality never comes into the equation.

As this book was being finalised Microsoft announced the launch of its Copilot application which makes extensive use of the Large Learning Model (LLM) technology developed by OpenAI. (The implications of this for workarounds are considered in Chapter 11.) In the launch post from Microsoft the company states

“GitHub data shows that Copilot promises to unlock productivity for everyone. Among developers who use GitHub Copilot, 88% say they are more productive, 74% say that they can focus on more satisfying work, and 77% say it helps them spend less time searching for information or examples.”

No analysis is provided as to whether productivity increases for developers (based on Microsoft internal data) is at all representative for knowledge workers in customer sites.

The problem of using productivity as a metric of success is that there is no agreed definition of productivity and the term itself derives from ‘product’ which can be characterised and counted. Despite this there is a widespread use by IT systems vendors of the extent to which implementing their technology will improve productivity. From an employee perspective there is inevitably concern that either they will be expected to work even harder in the future or that the implementation will put their continued employment at risk as the organisation uses the promised increase in productivity to reduce the number of employees, who of course represent a significant element of the costs of running the business.

The result is that employees in both IT and the business find themselves under increasing stress.

The pressure is on the IT department to deliver an implementation or an upgrade as quickly as possible. So long as all the process requirements can be ticked off as met there is no incentive to consider issues about the user experience, which may require additional work to deliver.

Functional and non-functional requirements

When it comes to specifying the requirements for an enterprise IT application the functional requirements are developed by business analysts.

The roles of a business analyst include

• Analysing a business problem or opportunity.
• Undertaking research to understand the context within which an application (or individual process) will be implemented.
• Identifying areas for improvement, exploring options and assessing effects of change and proposing success measures.
• Identifying and elaborating user and business needs to enable effective design, development and testing of services and business change.
• Advising on decisions related to prioritisation and relationships with other applications and processes.

From this work, using well-established techniques, functional specifications can be developed.

Establishing non-functional requirements is much more difficult. These relate to the way in which employees will use the application, often now referred to as the User Experience (UX). Many of these relate to usability, but this is itself a very broad concept.

A very helpful categorisation of core issues of usability has been developed by Hertzum (2010), setting out what he regards as six ‘images’ of usability.

• Universal usability—usability entails embracing the challenge of making systems for everybody to use.
• Situational usability—usability is equivalent to the quality-in-use of a system in a specified situation with its users, tasks, and wider context of use.
• Perceived usability—usability concerns the user’s subjective experience of a system based on his or her interaction with it.
• Hedonic usability—usability is about joy of use rather than ease of use, task accomplishment, and freedom of discomfort.
• Organisational usability—usability implies groups of people collaborating in an organisational setting.
• Cultural usability—usability takes on different meanings depending on the users’ cultural background.

This categorisation is important in moving the discussion away from a mechanistic approach to conformation with (in particular) the Web Accessibility Initiative guidelines.

Meeting user expectations.

Over the last decade the usability of web applications has increased significantly, led by the research conducted by consultancy companies such as the Nielsen Norman Group and MeasuringU.  The Web Accessibility Guidelines have been developed through the W3C process in cooperation with individuals and organisations around the world, with a goal of providing a single shared standard for web content accessibility that meets the needs of individuals, organisations, and governments internationally. The standards recognise that web applications are used by people with a wide range of physical and cognitive disabilities.

WCAG 2.0 was published in December 2008 and this was followed in June 2018 by the publication of WCAG 2.1.  The WCAG 2.2 Draft is scheduled to be finalised by May 2023.

The Guidelines and Success Criteria are organised around the following four principles, which lay the foundation necessary for anyone to access and use Web content. The core requirements are

Perceivable – information and user interface components must be presentable to users in ways they can perceive. This means that users must be able to perceive the information being presented (it can’t be invisible to all of their senses).

Operable – user interface components and navigation must be operable. This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform).

Understandable – information and the operation of the user interface must be understandable. This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding).

Robust – content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies. This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).

Work on WCAG 3.0 is in progress but the standard is unlikely to be published for several years.

WCAG 2.0 is approved as an ISO standard: ISO/IEC 40500:2012.

The ISO also publishes ISO/IEC 25010:2011(en) which has the sub-title ‘Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models’. This standard is concerned with quality and not accessibility.

According to the ISO web site ISO/IEC 25010:2011 defines:

1. A quality in use model composed of five characteristics (some of which are further subdivided into sub-characteristics) that relate to the outcome of interaction when a product is used in a particular context of use. This system model is applicable to the complete human-computer system, including both computer systems in use and software products in use.
2. A product quality model composed of eight characteristics (which are further subdivided into sub-characteristics) that relate to static properties of software and dynamic properties of the computer system. The model is applicable to both computer systems and software products.

The problem that organisations face is that it is very difficult to evaluate the extent to which non-functional requirements are being met. It is not possible to undertake user experience research until the application is very close to implementation, so close that fundamental changes cannot be made without incurring substantial additional costs and delaying the implementation. User experience testing on pilot or minimum viable product versions may well not scale. In addition the challenges being faced by acting as a systems integrator in migrating data from one system to another may not be apparent for some time.

Accommodating neurodivergent employees

The concept of neurodiversity dates back to the late 1990s as a way of describing a wide range of cognitive conditions such as autism, dyslexia and Attention Deficit Hyperactivity Disorder (ADHD). These are all ‘spectrum’ conditions and are often very difficult for both the person and the clinician/psychologist to identify. There are no remedial treatments for any of these conditions. People with these conditions find workarounds in both daily life and in the workplace in order to achieve as good a personal outcome as possible. We can gauge to a limited extent the problems faced by employees who are blind, colour-blind or have conditions that affect the way in which they can use a keyboard, touch screen or a mouse. There is no way in which we can appreciate the challenges faced by employees with a neurodivergent condition. The language of neurodiversity and neurodivergent conditions needs to be accommodated with care.

The work on accessibility often does not go far enough in ensuring that employees with a neurodivergent condition have an appropriate level of support in the workplace. As just one example, employees with dyslexia often benefit from being able to define a specific font that they find improves their level of readability, and also the background colour to the computer screen. These adaptions are often very difficult to implement on enterprise applications and it is not uncommon for an employee to have to reset their preferences each time they use the application (Churchill 2021).

Where an employee resorts to a workaround to accommodate their particular neurodivergent condition (or indeed, conditions) they may be even more reluctant to disclose the workaround they have adopted in case it leads to a more general discussion about the impact of their neurodivergence on their ability to undertake the roles and responsibilities that their position requires.

There is very little published research on the range of workarounds adopted specifically by employees with a neurodivergent condition in an enterprise setting. Das (2021) examines the issues arising in the case of neurodivergent employees working remotely and this gives an indication of the issues they would experience in an on-site situation.

Enterprise system implementation challenges

The implementation of enterprise applications is a major challenge for organisations of any size. Often organisations will outsource much of the implementation work to specialist system implementation companies, especially where the application is new to the organisation and so there is little or no internal experience to call on.

These challenges can be broadly categorised as

1. Stakeholder expectations and support. The business case for an ES usually involves the ability to integrate a range of different functions. Within the business these functions were owned by different senior managers, often at Board level. Gaining agreement on the expectations, and how the budget would be set and managed, turned out to be immensely time-consuming and fraught with internal power struggles.
2. Project management. ES implementations entail multiple phases: discovery and planning, design, development, data migration, testing, deployment, support and post-launch updates. Each phase resulting in a number of critical tasks, and all elements need to stay on track, which requires meticulous project management. Additionally, successful EA implementations required participation from all the groups that will be involved in developing and using the system. That can be incredibly challenging, because each department is juggling its ES project responsibilities with multiple other priorities.
3. Business as usual. Another aspect of project management is that business-as-usual has to be maintained. This can put extreme pressure on employees who may be having to use two different systems at the same time, one of which may not be fully functionable.
4. Project planning. Organisations often underestimated the time and budget necessary for a successful implementation because they had little prior experience of doing so. One of the most common causes of budget overruns was scope creep—when a business adds capabilities or features to the system that weren’t part of the original plan—and another is underestimating staffing needs.
5. Data integration. A key step in ES implementation is data migration, which typically involves moving data from multiple older systems into the ES database. The information may be spread far and wide across the organisation, buried in accounting systems, department-specific applications, and spreadsheets, with invariably different approaches being taken by individual subsidiaries and geographic locations.
6. Data quality. Because multiple departments interact with the same customers, products and orders, organisations often have duplicate versions of the same information in their systems. The information may be stored in different formats; there may be inconsistencies, like in addresses or name spellings; some information may be inaccurate; and it may include obsolete information such as customers or suppliers that have since gone out of business. In multi-national companies the application may need to work in multiple languages and accommodate local regulations on data privacy and on auditing.
7. Change management. An ES implementation typically means overhauling business processes to take advantage of the efficiency and productivity improvements possible with the new solution. Initial pilot testing may show that a process has not been well defined but making a change may well require other linked processes to be changed.
8. Post implementation. Moreover, the solution needed to evolve to support new business demands and technology. The project team needed to continue to manage the project after deployment, fixing issues and supporting new requirements as they come up. If the project team had been largely staffed by external consultants, either from the software vendor or an application partner, then much of the knowledge of the design of the system may not be immediately accessible to the organisation.

Electronic Health Record system implementation.

The starting point for EHR systems was a proposal in 1968 by Lawrence Weed, an American clinician, for a Problem Oriented Medical Record. This was the catalyst in the development of the “SOAP” note, an acronym based on Subjective, Objective, Assessment and Plan. An element of this development was the evolution of an encounter as being a communication between two or more individuals, at least one of whom is a member of the health care team. The communication may be direct such as a face to face or telephone conversation with the patient, or indirect such as a letter or report received from the hospital.

Electronic Health Record systems emerged gradually in the USA, where the widespread use of private medicine meant that there was a need to track patient treatments so that the patient could be billed. In Europe medical treatment was always free at the point of delivery. With the advent of web-based applications and the development of systems that could be used in general practice EHR system design was extended to track the history of a patient.

An important catalyst to growth was the creation by President George W. Bush of the Office of the National Coordinator for Health Information Technology, which outlined a plan to ensure that most Americans had electronic health records within the next ten years.

Additionally, these records were designed for healthcare providers to:

• Share information privately and securely with the patient’s authorisation.
• Help health care quality, prevent medical errors and reduce paper work.
• Improve administrative efficiencies and health care quality.

In the United States these systems work under HIPAA, a set of federal regulatory standards that outline the lawful use and disclosure of protected health information in the United States. HIPAA compliance is regulated by the Department of Health and Human Services (HHS) and enforced by the Office for Civil Rights (OCR).

To match the implementation challenges of EA systems the challenges with EHR applications include

1. Cost of implementation. Although hospitals are accustomed to making a significant expenditure in diagnostic and surgical equipment IT system investment has always been a challenge, even in the largely privatised US medical system. The benefits are also far less immediate than in diagnosis and treatment so making a business case for the investment is very difficult.
2. Data migration. A vital element of the implementation of an EHR is the conversion of a very significant archive of patient records, with no easy agreement on how far back in time the records should go. Even after initial implementation there is a substantial task to validate the records.
3. Staff training. Hospitals and clinics invariably find that staffing is a major concern in delivering high quality health care. There is also never a ‘down time’ in a clinical setting where training can be undertaken – hospitals work on a 24/7 basis so time to spend on training is very difficult to arrange, especially for more senior staff who are on-call throughout their working day.
4. Poor usability. ERP system vendors have considerable experience in the development of enterprise-wide systems. That is not the case in EHR application development where potential customers will have only limited, if any, prior experience with large-scale patient critical systems and the inevitable issues of usability.
5. Staff resistance. Poor usability inevitably causes staff at all levels to question whether the investment is going to improve patient outcomes, and can result in shadow systems (often manual) being maintained because of concerns about the efficacy of the EHR.
6. Data privacy. Another major challenge of EHR is the data privacy concerns of the patient and provider community. The stakeholders often voice concerns over the risk of data leakage due to a natural disaster or a cyber attack. The federal rule has imposed a national policy to protect the confidentiality of personal health data. In case of a security breach, the organisation may get into a legal hassle and have to spend millions of dollars to settle the dispute. Hence, it becomes a major responsibility of the provider to ensure the data security of the EHR systems.
7. Technical skills availability. This is one of the EHR implementation challenges often faced by small clinical establishments and private health practitioners. They may not have  the required hardware to support the EHR solution. nor the experience and expertise in implementation. It is a huge expense to build an in-house team with proper staff with adequate expertise and to buy hardware. This is a common reason for small and mid-sized healthcare providers delaying the EHR implementation process.
8. Lack of proper planning. EHR implementation brings in a cultural change in the organisation rather than a mere technological upgrade. Hence, the change in management aspects of EHR implementation become a real challenge. It needs to be strategically planned and commitment is expected from all stakeholders. Not having a structuralised plan for EHR implementation can lead to data breaches and cybersecurity threats to patient information. The successful implementation and sustainability of the EHR systems can be a far-fetched dream without a great amount of planning involved.

EA and EHR comparisons

The table below sets out an inevitably generalised comparison of the extent to which there are common issues with ERP (and most other enterprise scale applications) and EHR and where there are some significant differences.

The fundamental difference is that in the case of enterprise IT systems there is very unlikely to be any serious impact on employees and customers. With EHR systems a patient’s life expectancy is at risk and members of the clinical team could be found to have failed to provide the expected level of professional competence.

Enterprise application integration

Another common TLA in the IT sector is Enterprise Application Integration (EAI). The objective of the business is to integrate as many of its systems as possible into a single application, often using third-party applications.

Organisations can be at different levels of EAI, from applications existing separately to full integration where all applications share common data and workflows. More realistically, most will fall somewhere in between, with some applications working together and others not.

There are three core approaches to achieving a successful EAI solution.

Point-to-point integration. Data  is taken from one source, perhaps reformatted, and then ingested by the next application. This solution does not scale to situations where there is a sequence of processes, each of which involves some degree of reformatting of the initial data.

Hub-and-spoke integration. To overcome the process sequence issues it is also possible to use a hub-and-spoke approach to handle the reformatting and this can reduce latency delays that often occur with the point-to-point integration.

Enterprise service bus integration. This is an evolution of hub-and-spoke design in which all the applications use a set of standards to send and receive data or workflows. This can speed the integration and application process but requires very careful initial specification.

Whichever approach is chosen the application complexity increases significantly, and problems can arise if the applications are from multiple vendors. When the solution fails to meet expectations working out what is causing the problems and who should own the solution is far from easy.

Another issue is that the user interface may well be managed by the EAI solution and that means that employees who may be able to use each application successfully now find they have to learn a new user interface which may lack some of the functionality of the individual systems. The complexity of the integration process may well mean that changes to the user interface as a result of user feedback are difficult to undertake. The end result is that the quest for ‘ease of use’ through enterprise systems integration is offset by the lack of usability of the integrated system, again forcing employees to develop workarounds.

Psychological safety

The concept of employee psychological safety dates back to the 1950s but now has a high profile largely from the challenges that employees faced when adapting to remote working as a result of the Covid pandemic, and the resultant loss of 1-on-1 personal interaction to discuss workplace issues with colleagues and managers.

An influential paper on these issues was published in 2003 (Baer and Friese 2003) in which the authors argued that process innovations, defined as deliberate and new organisational attempts to change production and service processes, need to be accompanied by climates that complement the adoption and implementation of such innovations.

Process innovations = workarounds!

This paper goes to the heart of the matter when it comes to taking advantage of workarounds, and shadow IT, to improve process performance and personal recognition. As of the time of writing this book the paper had been cited 2344 times, which indicates both the value of this research and the scale of subsequent research. The most recent paper on this topic by Edmonson and Bransby (2023) provides a comprehensive overview.

The important point about psychological safety is that a lack of it creates a barrier to any sharing of a workaround or shadow IT for fear of recrimination from colleagues, managers and the organisation.

Global vs local

Enterprise applications are often implemented on a multi-country basis. Adaptation of these applications for other countries requires significant local knowledge. One of the earliest case studies (Soh et al 2000) of an enterprise application focuses on the extent to which these local adaptations were a source of friction among employees. There are also challenges in training employees in the use of these applications because of the need to support this on site, and perhaps to provide some or all of the training in a local language.

At one point in my career I was working as a sub-contractor to a US IT systems consultancy on an ERP implementation in one of the Gulf states. The implementation team were mainly American (who worked with US MM/DD date formats on all project documents), the stakeholders were nationals of the country, most of the middle level managers were British or Australian and the employees making use of the system were also nationals of the country but often had a very limited command of English and no prior experience of working with large-scale enterprise applications. This resulted in some interesting project meetings!

The bottom line

The implementation and management of large scale enterprise applications is very challenging, and is often a collaborative project between the organisation, the application vendor and a specialised systems integration company. Because of the technical challenges of the implementation (and subsequent upgrades) the requirements of employees for an application that they can use effectively with a minimal amount of training are often overlooked, especially as they may only become obvious when the technical implementation is completed. Much of the academic research into workarounds has focused on defining what characterises a workaround, and this is the subject of Chapter 4.

References

Baer, M. & Freise, M. (2003). Innovation is not enough: climates for initiative and psychological safety, process innovations, and firm performance. Journal of Organizational Behavior J. Organiz. Behav.24, 45–68. https://doi.org/10.1002/job.179

Churchill, E.F. (2021). Refactoring design to reframe (dis)ability. Interactions 28(3) 24-26

Das, M., Tang, J., Kathryn E. Ringland, K.E. and Piper, A.M. (2021). Towards Accessible Remote Work: Understanding Work-from-Home Practices of Neurodivergent Professionals. Proc. ACM Hum.-Comput. Interact. 5, CSCW1, Article 183 (April 2021), https://doi.org/10.1145/3449282

Edmondson, A.C. & Bransby, D.P. (2003). Psychological safety comes of age: observed themes in an established literature. Annual Review of Organizational Psychology and Organizational Behavior, 10, 55-78. https://doi.org/10.1146/annurev-orgpsych-120920-055217 https://www.annualreviews.org/doi/pdf/10.1146/annurev-orgpsych-120920-055217

Hertzum, M. (2010). Images of usability. Journal of Human–Computer Interaction, 26,(6), 567-600            https://www.tandfonline.com/doi/abs/10.1080/10447311003781300

Newell, S., Wagner, E.L & David, G. (2007). Clumsy information systems: A critical review of enterprise systems in Desouza, K. C. (2007). Agile information systems: Conceptualization, construction, and management. Elsevier. https://doi.org/10.4324/9780080463681

Soh, C., Kien, S.S., & Tay-Yap, J. (2000).  Enterprise resource planning: cultural fits and misfits: is ERP a universal solution? Communications of the ACM, 43(4), 47-51 https://doi.org/10.1145/332051.332070