Malleable End-User Software
- First Online:
- Cite this article as:
- Richter, A. & Riemer, K. Bus Inf Syst Eng (2013) 5: 195. doi:10.1007/s12599-013-0260-x
- 162 Views
1 User Software Brushed Against the Grain
Traditionally, enterprise software is developed and introduced with the aim to support clearly defined usage scenarios within specific business process contexts. Malleable end-user software (MEUS) is different. A recent MEUS example is social software. Typically employed to enable communication in and between corporations, social software has gained importance for corporations in the past years (e.g., Back et al. 2012; Stocker et al. 2012). At the same time it has become obvious that social software challenges established information systems methods (McAfee 2009; Richter et al. 2012). We argue that a fundamental understanding of this class of software and its characteristics is needed.
This article attempts to contribute to this understanding by highlighting the implications of MEUS for software development and management (including planning, implementation, and measuring of success). We will show that traditional technology adoption theories are inadequate to capture the application of MEUS. Since MEUS is not developed for a specific purpose, individuals are typically unable to judge the usefulness of such software before they have actually used it. Traditional IT management faces similar challenges, as the introduction of MEUS cannot be planned according to an anticipated outcome. While traditional end-user software is developed and introduced with the aim to solve a particular problem in everyday work practice, malleable end-user software aims to bring about new or novel usage possibilities.
2 User Software with and Without Purpose
In the following we distinguish between purpose-specific and malleable end-user software. In doing so, we focus on software that is used by end users in their workplace in a corporate context. We demarcate end-user software from IT infrastructures and automated IT systems which normally are not operated by end users as well as from Internet applications (e.g., sales portals) that do not serve as workplace tools.
2.1 Purpose-Specific End-User Software (PEUS)
Purpose-specific end-user software is developed and introduced with the aim to solve an existing corporate problem or to immediately improve an existing user task. Typically, there is a clear vision as to the intended benefits for a particular business process. Typical examples are ERP and CRM systems and similar process-oriented software. Adoption and use of PEUS is thus prescribed and communicated in a “top-down” manner by the corporate management, and the particular ways of using the software are determined both by particular software features and the responsible managers. The intention is to have tasks carried out in a particular way and to bring about specified improvements to existing business processes. The underlying rationale is typically one of gaining efficiency, achieving standardization, rationalization, or compliance with regulations. At the same time, however, this bears the risk that users react strongly to the introduction of PEUS if the intended changes to their work practices do not make sense from their point of view.
Recently, a change has become evident in the world of purpose-specific end-user software. Role specifications and process models make way for increasingly individual forms of work (Wulf 2009). The SAP platform NetWeaver is an example that allows to support business processes by combining and bundling specific software services in a straightforward way (Heitmann 2006, cited in Wulf 2009). This modular concept makes it possible to adapt the platform to the requirements of work practices and to continuously improve business processes. However, malleability is not the result of modularity or interpretive flexibility (e.g., Bijker et al. 1989) in the sense of technical customizability, as we will demonstrate in the following section.
2.2 Malleable End-user Software (MEUS)
The main characteristic of malleable end-user software is its inherent flexibility and openness when enabling and supporting a wide variety of work practices without the need for technical customization. Instead of focusing on a particular purpose or providing a solution to a problem, MEUS aims to create potentials and new opportunities for organizational innovation. The main aim is to support existing or to enable new work and communication practices. Typical MEUS examples are communication and cooperation systems (e.g., Skype, Lotus Notes, etc.), office software (word processing and spreadsheets), as well as a wide range of new Internet-based tools for information storage and editing (e.g., DropBox or Evernote). In the following we draw on social software as an example. Social software is generally employed to support social interaction among employees. However, as both purpose and content of such interactions are open-ended and not prescribed by the software, a wide range of possible ways exist to appropriate such platforms. Consequently, this results in quite distinct, interaction-based usage practices that are often closely confined to a certain context. For example, social software has been applied for solving problems, distributing information, coordinating tasks, classifying knowledge, or even for managing projects (see Riemer et al. 2010).
3 Malleable End-User Software and IS Theory
Malleability as a characteristic of end-user software challenges the applicability of existing theories such as the widely known adoption theories Technology Acceptance Model (TAM) (Davis 1989) and Unified Theory of Acceptance and Use of Technology (UTAUT) (Venkatesh et al. 2003). In essence, these theories model the adoption of new workplace technologies as a decision made by individuals regarding the use or non-use of a new IT artifact (Bagozzi 2007). In doing so, they focus on the “if” of adoption (does it occur?) and not the “how” (what happens during adoption?). The decision regarding usage or non-usage is, among other variables, dependent on the perception of the usefulness of the software for the individual’s tasks. Data in corresponding studies is typically collected before adoption takes place and the dependent variable is modeled as the intention to use.
However, the problem arises that the usefulness and potential role of MEUS for one’s work practice cannot easily be determined and anticipated a priori due to its flexibility and lack of in-built purpose. In essence, these existing theories do not account for this fact which violates a core assumption. Consequently, such theories are not suitable for explaining user adoption of malleable end-user software. At the same time, this challenges the validity of existing studies built over these theories, such as studies investigating the adoption of social software in the workplace.
In order to develop a better understanding for the adoption of malleable end-user software new approaches are needed. User acceptance should not be modeled as an individual decision made for a well-understood artifact, but rather as a social process of appropriation in which the software is interpreted and “placed” within the context of existing work practices (Riemer and Johnston 2012).
Appropriation can generally be understood as “the way in which technologies are adopted, adapted and incorporated into working practice. […] Appropriation relies on flexibility in both practice and technology” (Dourish 2003, 5). Appropriation needs to be treated as a process, because the users have to gain practical experience with the software and over time find a place for it within their own practice. This process is always a social process since the work practices are by definition social practices that are shared and socially negotiated (Schatzki 2010). Therefore any employment of a new software has to be socially negotiated as well. The term appropriation stresses that the users have to collectively adopt the software and make it “their own” (Riemer et al. 2012). Hence it is necessary to develop new process theories regarding technology acceptance that are suited to grasp the phenomenon of appropriation of malleable end-user software. Besides a good understanding of technological developments this requires methods that are able to capture and examine social practices, which calls for an interdisciplinary approach.
4 Malleable End-User Software in Practice
Generally, malleable end-user software is not developed for a clearly defined usage scenario within a specific business process and cannot be understood by means of its feature sets. Rather, its benefits materialize only when the software has found its place in the everyday work practice of users. This necessitates active appropriation on part of the users, which entails practical experimenting and reflecting on emerging usage scenarios. Since MEUS does not prescribe particular forms of use, it is necessary for users to discover emerging potentials against the background of their own working practices and make room for the new software within the existing practice “toolbox”. However, since it is not possible to plan such appropriation towards an a priori known end state, it is also necessary to rethink the planning, introduction and measuring of success for malleable end-user software.
4.1 Planning: Scenario-Based
The above discussion shows that the selection of MEUS cannot simply be based on a traditional task requirement analysis; rather, the selection of malleable end-user software should draw on scenario analysis. Scenarios can capture and illustrate potential aims and substantiate benefits associated with software use, which allows decision makers to set priorities. For example, if social software is intended to serve as a discussion forum it is reasonable to evaluate whether or not a particular product is able to support all associated work practices (see Richter et al. 2012).
4.2 Introduction: Step by Step
The introduction of MEUS to the users’ practice ideally takes place in an open, dynamic and voluntary way that does not focus on rigidly predetermined outcomes. This contradicts established business practices that typically attempt to associate every project with a concrete and measurable outcome. However, this does not mean that the appropriation process cannot be supported. For example, it is worthwhile to develop context-specific use cases that might be based on and adapted from existing case examples taken from other companies. This should be an iterative process in which users step by step uncover the potential of the software in the context of their own work practices, develop new ways of applying the software and share these emerging use cases with the wider user group. Given the discursive nature of this approach it is important to find a tradeoff between granting a high degree of flexibility and ensuring that the emerging ways of software use converge over time. For example, a set of guidelines might provide a framework for software use that still leaves enough space to explore new usage practices. At the same time, users should be supported in clearly separating and demarcating existing MEUS regarding their emerging purposes while simultaneously finding appropriate forms of usage for the new product. This process can hardly be determined from the outside and should be moderated internally, for example in workshops that include both users and product owners. In doing so, both the potential users and the management are confronted with the uncertainty that resulting benefits are hard to foresee. At the same time there is a risk that users may not see an immediate benefit in the software, while also lacking time to experiment with the software to explore new work practices.
4.3 Measuring Success: Case by Case
The measurement of use and resulting benefits of malleable end-user software is difficult due to the lack of correspondence with one particular business process. Consequently, any evaluation should always take place against the backdrop of a specific usage context. For example, it makes a marked difference for measuring success whether the software supports a team working collaboratively on documents or a companywide community that exchanges ideas and experiences. For both contexts it is possible to gather concrete experiences over time, for example of how much parallel work was avoided and how extensively the software was used in each case.
Classification of end-user software
In the context of a business process
Cannot be a priori pinpointed
Managed, prescribed, linear
Open, explorative, dynamic
Users see software in conflict with their work practices (resistance)
Users do not find any immediate benefit in the software
In this article we have characterized a particular class of end-user software. We have discussed theoretical and practical implications for the planning, introduction and evaluation of such software. To this end, we have highlighted the constituting characteristics of malleability and contrasted them with those of traditional purpose-specific software. We have further highlighted that malleable end-user software is able to support a wide range of corporate usage practices and is not directly associated with one or more concrete business processes. We have pointed out important implications for practice. For example, we have argued that due to the lack of in-built purpose it is necessary to organize the introduction of MEUS as an open-ended, dynamic, and voluntary process in which management sets the context rather than determines outcomes. Hence, malleable end-user software not only challenges established IS theories of technology adoption, but also requires a reconsideration of the management of the planning, introduction and measuring success. With the increased employment of different forms of social software in and between companies these topics will progressively gain importance. This requires the information systems field to come up with appropriate theories and management concepts.