Communications of the ACM
Home/Magazine Archive/January 2017 (Vol. 60, No. 1)/Bottom-Up Enterprise Information Systems: Rethinking.../Full Text
Contributed articles
Bottom-Up Enterprise Information Systems: Rethinking the Roles of Central It Departments
Credit: Olivier Le Moal
Cross-functional, enterprise, and infrastructure systems integrate information across an organization for use by multiple stakeholders.14,22 Development or configuration of these large, multimillion-dollar projects is normally overseen by top management in conjunction with the central information technology (IT) department.21 There is, however, an increasing number of such systems arising from functional areas or departments in which users work, with central IT and top management being challenged to implement controls on these systems only after they go live.13
Key Insights
Consider the following examples based on interviews conducted in recent years. Half were with chief information officers (CIOs). The other half were with their end users. Our aim was to understand the factors leading to bottom-up enterprise information systems. The first example is from a mid-size hospital in Auckland, New Zealand, where doctors had contracted with a paging service. In the second, university faculty adopted the Moodle learning-management system instead of their locally supported system.
CIO: "This guy ... who built this thing and hosted it out of a literally a garage somewhere in London, and they said, 'Well, we'd like to trial this.' And he said 'fine.' So they set up a trial using that hosted environment ... they actually implemented it into something like 12 or 16 wards. It was just so successful that after the first month it grew like wildfire."
Another CIO: "Blackboard was the official system ... People said, 'We want to bring the Moodle environment test mode, and it will only be in test mode, and we will see how that goes... so they started using lectures on them, so it became a production environment. But it was under their control sitting somewhere on some server, and they've got an organization functionally dependent on shadow IT."
Bottom-up enterprise information systems are not sanctioned by central IT, the official group within an organization responsible for IT. Nevertheless, they are implemented on an organizationwide or, minimally, a cross-functional basis. They exhibit three key characteristics. First, they are either enterprisewide, or function spanning, so the technology is used across multiple departments. Second, IT implementations are developed, configured, or procured by end users who do not necessarily have sophisticated technology skills. Third, implementation decisions are made when top management and central IT exert little formal control and have no official governance over the project.
In this article, we investigate the emergent phenomenon of such bottom-up enterprise information systems to identify causal factors and offer recommendations for how to best manage it. Insights are derived from three sources. First and foremost, the paired CIO and end-user interviews provide concrete examples of how bottom-up enterprise information systems are emerging and being managed from which some general inferences can be made. Second, our interview data is complemented by the practitioner literature from which we derive a framework for understanding the context of bottom-up enterprise information systems. Finally, the theoretical literature, specifically on distributed leadership, provides insights into how the phenomenon should be managed. The result is a set of recommendations for rethinking the role of central IT to effectively manage bottom-up enterprise information systems.
Drivers of Bottom-Up Systems
The two types of main drivers of bottom-up enterprise information systems are external and internal:
External. The primary reason bottom-up enterprise information systems are emerging today is changes in technology, especially since the mid-2000s, including:
Simpler/"standardized" application distribution models. Historically, enterprise information systems have been configured and installed by specialized vendors. Such applications are now available in downloadable form. For example, ADempiere (http://adempiere.org) is an open source enterprise resource planning system; Moodle is an open source learning-management system. Cloud versions of enterprise software are available; for example, SAP Business ByDesign (http://go.sap.com/product/enterprise-manage-ment/business-bydesign.html) is a cloud-based version of SAP.
Changing IT application cost structure. Historically, new IT applications were expensive capital costs, requiring central IT to secure large budgets in advance.6 In contrast, many modern software packages are paid for as ongoing, operational costs; for example, SAP Business ByDesign is accessed through a monthly subscription. Costs are amortized over a longer period, so functional areas reallocate money from routine budgets to acquire new applications, thereby bypassing financial checks when procuring software.
CIO: "They can reprioritize the definition of what's an operational expenditure versus a capital expenditure, and, if they have some 'underspend,' they can get a developer in and pay just an hourly rate and get some developer time."
Accessible third-party technical support. One factor impeding the ability of functional areas to procure IT products and support independently has been their lack of IT expertise.12 However, contemporary applications (such as Microsoft's Active Directory and TeamViewer) allow monitoring and control of remote computational devices. Functional areas can outsource some IT to a vendor, thereby bypassing both central IT and top management.
User: "... at the moment it's hosted externally ... it's an Internet-based system, which means that our staff can access it anywhere, it means ... we can make changes quickly ... Stuff that doesn't happen through our centralized IT group. Well, it happens, but over a very long period of time."
Standardization of interfaces. Many enterprise solutions are Web-based, so they work well on most devices. It is thus possible for users to bypass the physical organizational IT infrastructure. Even when organizations block bottom-up enterprise information systems on internal networks, users can still employ personal devices for access.
Together, these external drivers provide users access to complex, multi-function systems that were previously inaccessible.
Internal drivers. There are two main internal organizational drivers:
Inherent limitations of centrally managed governance. Centrally managed governance systems usually favor large, highly visible projects with quantifiable bottom-line benefits. Smaller, possibly exploratory, projects may be neglected. Such projects may have intangible, difficult-to-quantify benefits. The following quote from a CIO illustrates a bias inherent in many centrally managed IT procurement processes.
CIO: "[Person] said we need more e-learning. I said, absolutely, but fat chance that it's going to make the priority list based on what we are doing. And he said, look I found this online company; it's an open source product. All I need is $20,000 to get started."
This e-learning case highlights little "objective" basis for top management to support such an endeavor. Convincing top management to take notice may indeed be impossible. However, when projects are successful, they can spread quickly, as in the hospital paging service.
Organizational processes. Some organizational processes are ineffective or dysfunctional, making them difficult or costly to work around;24 alternatively, processes may change frequently in today's dynamic business environment. Functional departments may thus implement bottom-up enterprise information systems because they do not perceive feasible alternatives as being available.
In one Moodle implementation, a particular university's rules prevented users from enrolling students who attended "short" courses (such as adult education and executive MBA). These students did not go through the complete university student-enrollment process and were not issued university student-identification cards and numbers, a prerequisite for using the existing learning-management system. Users employed Moodle to enroll and manage these students. Here, the central IT system did not cater to a significant (and highly profitable) sub-segment of the university's customer base. Functional areas serving that base independently supported them through their own local initiatives.
IS researchers have argued enterprise information systems should not be built in a top-down manner but instead facilitate bottom-up innovation.4 Successful implementation of enterprisewide systems (such as enterprise architecture)8 will increasingly require negotiation and dialog rather than the imposition of ideas from central IT.25 This bottom-up approach to building enterprise systems now occurs worldwide, regardless of central IT desires. For corporate management, no longer is it an issue of whether bottom-up enterprise information systems are "right" or counterproductive but rather how to deal with the reality of their existence.
Rethinking Central IT
The relevant challenges involve three questions for IT management: How will bottom-up enterprise information systems change the way IT is managed? What should central IT do about the phenomenon? And what is the right mind-set to manage the IT landscape under such change?
Central IT's role. To address the first two, we adopt concepts from the Information Technology Infrastructure Library (ITIL, http://www.itlibrary.org/),2,9,15,19,23 a "best practice" industry framework providing an overview of the responsibilities of an IT department. It is well accepted by the IT industry17 that central IT departments that follow ITIL generally perform better than those that do not.10,17 Consistent with the strategic information systems literature (such as in Zoet et al.25), ITIL views the IT function as concerned with services, categorizing IT functions into five groups. The accompanying table summarizes how bottom-up enterprise information systems will change central IT's practice with respect to these five process groups.
Service strategy. Service strategy is concerned with articulating an IT strategy and aligning IT processes with the overall organizational vision and direction.2 Bottom-up enterprise information systems create greater unknowns and uncertainty for IT service strategy; for example, part of the service strategy is projecting resource needs and ensuring an organization has sufficient capacity to run its future IT. When creating bottom-up enterprise information systems, functional areas may provide their own hardware, databases, and other critical infrastructure. Alternatively, they may employ software-as-a-service in which software is licensed on a subscription basis. Regardless, bottom-up enterprise information systems still consume central IT resources; for example, network load may be increased. If central IT is not aware of bottom-up enterprise information systems, it simply cannot plan for it.
Central IT needs to transform itself from "geeks on the other floor" to "our IT support next door."
Bottom-up enterprise information systems make human resource planning difficult because service-desk response becomes more complex. The support responsibility for bottom-up enterprise information systems can never wholly lie with functional areas because the infrastructure provided by central IT affects the performance of these systems; for example, an operating system or browser upgrade could be incompatible with a bottom-up enterprise information system, rendering it non-functional. Solving this human-resource-planning problem requires central IT budget for and dedicate people and money to it.
Finally, bottom-up enterprise information systems may not be aligned with an organization's strategy. The Moodle example violates a strategy of providing students with a consistent experience across all courses. Some faculty members employ Blackboard (http://blackboard.com/) and others Moodle. Dealing with such conflicts is challenging for central IT due to difficulties leveraging organizational power to convince functional areas to cooperate. In the Moodle example, faculty members use it knowing Blackboard is the officially sanctioned system. Discussion, understanding users' constraints (such as when students cannot be registered in the official system), and compromise are all necessary for resolving any ensuing tension.4
Dealing with bottom-up enterprise information systems thus requires central IT to devote a greater proportion of its workforce at all levels to service strategy. At the lowest level, IT personnel must engage with functional areas to understand what they are doing. Information is then transmitted to central IT, enabling better planning. At the middle levels, planning and projection require additional effort by IT personnel. At the highest levels, more effort is required to negotiate and coordinate functional areas to ensure the IT landscape across the organization is in alignment with overall enterprise strategy.
Service design. Service design focuses on development of new services for an organization,9 including new software, applications, and infrastructure, as well as acquiring vendor IT products. With bottom-up enterprise information systems, central IT's role in service design is diminished. Nevertheless, there remain two critical roles for IT. First, central IT is a repository of organizational-level requirements that functional areas often do not consider;8 for example, in one interview we conducted with a government organization in New Zealand, a user described a contract with a vendor to provide citizen services. We asked how the New Zealand Privacy Act was being addressed, given a vendor had access to the data of private citizens. The interviewee declined to answer. Central IT may be aware of privacy, the regulatory environment, and other broader organizational issues, but the functional areas may not be. It then becomes the responsibility of central IT to educate functional areas about these requirements; for example, in one safety-critical manufacturing organization, the functional areas were reminded that improperly designed IT affecting the manufacturing process could cause the organization to lose its operating license. The organization allows other forms of bottom-up enterprise information systems, as in bottom-up financial IT. However, due to legal requirements, user-developed IT in the manufacturing process is strictly forbidden.
User: "We have to adhere stringently to what we call GMP [good manufacturing process] requirements ... We get audited by [organization] and auditors come in and spend time talking to our IS manager about how those systems are managed and maintained and all that sort of stuff."
For bottom-up enterprise information systems to succeed, central IT must be willing to cede power to functional areas and vice versa.
Second, central IT has a responsibility in guiding and structuring the implementation or vendor-selection process. Vendors tend to have an advantage because they negotiate more contracts for their class of service than do clients.20 Central IT negotiates more IT contracts than users, resulting in greater competence in such matters. Also, central IT is generally more aware of the broader issues in implementation; for example, functions might neglect nonfunctional testing (such as load testing). In the case of the hospital using a paging service mentioned earlier, central IT struggled to ensure that the paging service was supported by reliable infrastructure, an issue users had not considered.
In bottom-up enterprise information systems, although central IT's role in service design might appear diminished, that role remains important. Specifically, central IT becomes the repository of shared organizational knowledge (such as policies for dealing with vendors) and organizational-level (as opposed to functional-level) requirements. Central IT must thus engage with functional areas and/or vendors to ensure bottom-up enterprise information systems remain aligned with the overall enterprise vision and architecture.
Service transition. Service transition includes processes associated with integrating a new service design with existing processes;19 typical service-transition processes are change management and training. Because functional areas are more entrenched in their own operations, they tend to be competent in service transition. However, they also tend to underestimate the cost and effort required; for example, one of the first ways central IT learns about bottom-up enterprise information systems is when functional areas request assistance to help with maintenance when the original developer leaves an organization. Here, the functional areas failed to adequately plan for training of maintenance personnel.
Central IT's role in service transition is thus to ensure that service transition is planned for and actually occurs. This role is similar to central IT's role in service delivery, in that central IT brings knowledge from previous projects (such as recognizing that service transition is important) to the new bottom-up-enterprise-information-system implementation.
Service operation. Service operation focuses on ensuring continuity of service.23 The service desk, ongoing maintenance, ensuring business continuity in the event of a fault, and disaster recovery are all elements of service operation. For bottom-up enterprise information systems, the role of central IT in service operation is complex. First, bottom-up enterprise information systems exist as just one interconnected part in an organization's IT landscape. For bottom-up enterprise information systems to perform well, they must connect to the corporate network, operating system, and firewall, each of which must function well. Furthermore, bottom-up enterprise information systems and these elements must be compatible. As a result, effective service operations for bottom-up enterprise information systems require coordination between central IT and the functional areas. Lack of coordination can indeed create embarrassing situations for CIOs.
CIO "... the guy in Sydney who ran the brand there saw an opportunity to improve on this customer service and he hired a young programmer to come in and build a system for him. ... Eventually, we found out about it because our CEO went there, and he came back to NZ and said to me, 'This is bloody good. Why don't we have it everywhere?,' and I said, 'What is it?'"
Furthermore, functional areas may be unaware of critical elements of effective service operations practices. In the hospital-paging example, the functional areas contracted for service without considering the implications of network or hardware failure. Central IT eventually helped move the paging service onto a network provider that guaranteed a satisfactory level of availability.
With regard to service operations, central IT has three roles. First, it continues to manage much of the enterprise infrastructure (such as networks, servers, and computers). Second, it coordinates with individual functional areas' service desks to ensure continuity of operations across the enterprise. And, finally, it is the repository of organizational service-desk best practice and advises the functional areas.
Continual service improvement. Continual service improvement explores how organizational IT service delivery can be improved.15 Managing continual service improvement becomes more complex for central IT because bottom-up enterprise information systems increase the complexity of the IT landscape. Also, because IT assets are owned by functional areas, these areas often must be given a place in planning for continual service improvement. Consider an attempt to rationalize an organization's IT vendors. In a traditional environment, central IT needs to engage only with central IT personnel to do so, because all vendors are managed by central IT. However, with bottom-up enterprise information systems, vendors contract with functional areas, rather than with central IT.
From the perspective of continual service improvement, central IT's role is thus to remind functional areas of the importance of reviewing their services from an improvement perspective, consult on best practices for improving service, and help coordinate improvements across the enterprise. By implication, in environments where bottom-up enterprise information systems are employed, central IT increasingly becomes a coordinating and advisory body, representing higher-level organizational interests.8 Operational concerns (such as design, implementation, maintenance and support, change management, training, and vendor management) devolve to functional areas. Note that central IT continues to have an operational role, albeit a diminished one compared to traditional roles with no bottom-up development. At the strategic level, central IT transforms from a function that declares the appropriate technology platforms to a consultative function.
Central IT Leadership
This coordinating and advisory role requires a change of mind-set to succeed. IT leadership may no longer be the purview of the central IT function; rather, it will be distributed across functional areas. IT consulting firm Gartner (http://www.gartner.com/technology/home.jsp) has, since 2013, suggested that marketing within an organization may spend more on IT than central IT would spend.7 Successful distributed leadership depends on four critical ingredients: balance of power, role blurring, trust, and trusteeship.1,5
Balance of power. Balance of power is created by results from bottom-up enterprise information systems. Central IT, the functional areas, and the vendor (if one exists) can all be the source of unsatisfactory outcomes. Balance of power means increasingly informal, socially driven mechanisms, or relational governance18 will be applied to manage IT issues. It is difficult for IT management to exert formal power over others who possess similar degrees of formal power or exercise it on those not in a direct reporting line (such as central IT to the functional areas).
A promising foundation for effective relational governance is strong social capital consisting of three equally important ingredients:3,11
Physical connection. Structural social capital is associated with one's ability to physically connect with others; for example, if central IT is physically located on a floor or building different from users, structural social capital is generally low;
Shared language. Cognitive social capital is associated with shared language. Central IT thus has better social capital with the accounting department if it can use accounting terms correctly. However, cognitive social capital is not simply associated with professional language; for example, central IT personnel who graduate from the same university as the accountants are likely to facilitate cognitive social capital; and
Building bonds. Relational social capital focuses on building bonds through favor exchanges, positive interactions (such as shared parties), and trust-building activities.
Central IT must carefully weigh its social capital in this new landscape; for example, it may not want to isolate itself on a separate floor from the functional areas. Similarly, it may want to consider whether the language it uses or the culture within central IT isolates it from other functional areas and from senior management. Central IT needs to transform itself from "geeks on the other floor" to "our IT support next door."
Role blurring occurs when one party can replace others if required.1,5 Role blurring requires personnel within central IT to gain an accurate understanding of the nature of the functional areas. They must have sufficient technical capability to understand the vendor. Likewise, IT personnel within the functional areas must expand their IT skills so they can carry out, say, system design. Similarly, vendors must have a degree of understanding of the businesses with which they engage.
An organization having bottom-up enterprise information systems is likely to require IT professionals to acquire a more "T-shaped" skill profile, with broad knowledge of a wide variety of skills and deep knowledge in one area.16 Role blurring is related to cognitive social capital. Central IT personnel must understand the language of the functional areas, even as they communicate their concerns effectively.
Trust. Trust is the degree to which each party believes the other will act in good faith. This requires central IT and the functional areas to build rapport. Interestingly, the IT personnel who often have the most contact with users work with service support, making them best positioned to initiate the building of rapport. However, many central IT departments often treat service support as strategically unimportant, as evidenced, when, say, they outsource it. Central IT might consider how doing so denies itself the opportunity to better engage with functional areas to build necessary rapport.
Trusteeship. Trusteeship requires each party to have the ability to audit and veto actions of the other parties. For bottom-up enterprise information systems to succeed, central IT must be willing to cede power to functional areas and vice versa. Trusteeship is important due to the greater degree of coordination required to make bottom-up enterprise information systems truly successful. Functional areas and central IT must be able to see into each others' processes to ensure IT systems are not duplicated and are able to work together. Functional areas in organizations with bottom-up enterprise information systems must be open and transparent with central IT, ensuring this coordination occurs.
User: "... this committee was [the CIO]'s idea. Let's understand what [bottom-up enterprise information systems] are out there. Let's gather all the information. We are not going to hit people on the head. We want them to be open to say, 'What have you got? We are going to try and help you. We've got a better solution or support the solution you've got.'"
Conclusion
This article has examined bottom-up enterprise information systems to understand why they are being developed and suggest how they might be managed more effectively. Modern technology (such as open source software, outsourcing, and cloud computing) enable users to bypass central IT to procure or configure their own enterprise information systems. Coupled with inherent organizational limitations, the result is bottom-up enterprise information systems becoming a new reality in many organizations. Managing such systems requires central IT to be a collaborative partner that guides functional areas toward effective IT practices. Central IT's operational role may diminish as the functional areas assume increased duties. However, when IT roles are distributed across the organization, additional coordination is required by central IT, functional areas, and vendors alike. Practices based on distributed leadership include establishing a balance of power across central IT and the functional areas, role blurring, or having both central IT and functional areas learn one another's skills and concepts, develop trust, and assume trusteeship to help ensure success in contemporary organizational environments.
Acknowledgment
This research was supported by DesignerTech, the University of Auckland, and the J. Mack Robinson College of Business at Georgia State University.
References
1. Bolden, R. Distributed leadership in organizations: A review of theory and research. International Journal of Management Reviews 13, 3 (Sept. 2011), 251–269.
2. Cannon, D. ITIL Service Strategy. The Stationery Office, Norwich, U.K., 2011.
3. Chua, C.E.H., Lim, W.K., Soh, C., and Sia, S.K. Enacting clan control in complex IT projects. MIS Quarterly 36, 2 (June 2012), 577–600.
4. Ciborra, C. From thinking to tinkering: The grassroots of strategic information systems. The Information Society 8, 4 (1992), 297–309.
5. Denis, J.-L., Langley, A., and Sergi, V. Leadership in the plural. Academy of Management Annals 6, 1 (June 2012), 211–283.
6. Dos Santos, B.L. Justifying investments in new information technologies. Journal of Management Information Systems 7, 4 (Spring 1991), 71–90.
7. Golden, B. As CMOs grab IT budget from CIOs, cloud CapEx and OpEx shift. CIO Magazine (Jan. 28, 2013).
8. Greefhorst, D. and Proper, E. Architecture Principles: The Cornerstones of Enterprise Architecture. Springer-Verlag, Berlin, Germany, 2011.
9. Hunnebeck, L. ITIL Service Design. The Stationery Office, Norwich, U.K., 2011.
10. Iden, J. and Eikebrokk, T.R. Using the ITIL process reference model for realizing IT governance: An empirical investigation. Information Systems Management 31, 1 (2014), 37–58.
11. Kirsch, L.J., Ko, D.-G., and Haney, M.H. Investigating the antecedents of team-based clan control: Adding social capital as a predictor. Organization Science 21, 2 (Apr. 2010), 469–489.
12. Ko, A.J., Abraham, R., Beckwith, L., Blackwell, A., Burnett, M., Erwig, M., Scaffidi, C., Lawrance, J., Lieberman, H., Myers, B., Rosson, M.B., Rothermel, G., Shaw, M., and Wiedenbeck, S. The state of the art in end-user software engineering. ACM Computing Surveys 43, 3 (Apr. 2011), 1–44.
13. Lacey, C. Shadow IT Goes Mainstream. Unisys blog, May 6, 2015; http://blogs.unisys.com/financialindustryinsights/shadow-it-goes-mainstream/
14. Liang, H., Saraf, N., Hu, Q., and Xue, Y. Assimilation of enterprise systems: The effect of institutional pressures and the mediating role of top management. MIS Quarterly 31, 1 (Mar. 2007), 1–29.
15. Lloyd, V. ITIL Continual Service Improvement. The Stationery Office, Norwich, U.K., 2011.
16. Madhavan, R. and Grover, R. From embedded knowledge to embodied knowledge: New product development as knowledge management. Journal of Marketing 62, 4 (Oct. 1998), 1–12.
17. Pollard, C. and Cater-Steel, A. Justifications, strategies, and critical success factors in successful ITIL implementations in U.S. and Australian companies: An exploratory study. Information Systems Management 26, 2 (Apr. 2009), 164–175.
18. Poppo, L. and Zenger, T.R. Do formal contracts and relational governance function as substitutes or complements? Strategic Management Journal 23, 8 (May 2002), 707–725.
19. Rance, S. ITIL Service Transition. The Stationery Office, Norwich, U.K., 2011.
20. Saunders, C., Gebelt, M., and Hu, Q. Achieving success in information systems outsourcing. California Management Review 39, 2 (Dec. 1997), 63–79.
21. Simonsen, J. Involving top management in IT projects. Commun. ACM 50, 8 (Aug. 2007), 53–58.
22. Star, S.L. and Ruhleder, K. Steps toward an ecology of infrastructure: Design and access for large information spaces. Information Systems Research 7, 1 (Mar. 1996), 111–134.
23. Steinberg, R. ITIL Service Operation. The Stationery Office, Norwich, U.K., 2011.
24. Wagner, J.A. The organizational double bind: Toward an understanding of rationality and its complement. Academy of Management Review 3, 4 (Oct. 1978), 786–795.
25. Zoet, M.M., Heerink, A.W., Lankhorst, M.M., Hoppenbrouwers, S.J.B.A., and Stokkum, W.v. An agile way of working. In Agile Service Development: Combining Adaptive Methods and Flexible Solutions, Springer-Verlag, Berlin, Germany, 2012, 111–140.
©2017 ACM 0001-0782/17/01
Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and full citation on the first page. Copyright for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, or to redistribute to lists, requires prior specific permission and/or fee. Request permission to publish from [email protected] or fax (212) 869-0481.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2017 ACM, Inc.
No entries found