Motives for Feral Systems in Denmark

Motives for Feral Systems in Denmark

Torben Tambo (Aarhus University, Denmark), Martin Olsen (Aarhus University, Denmark) and Lars Bækgaard (Aarhus University, Denmark)
Copyright: © 2014 |Pages: 32
DOI: 10.4018/978-1-4666-5027-5.ch007
OnDemand PDF Download:
$37.50

Abstract

Feral systems have largely been regarded as the users’ response to discrepancies between official IT software systems and actual business processes. Inadequacies, discrepancies, and absence of systems support to work processes might lead to users initiating systems development themselves: systems involving any combination of software and manual processes. Feral systems are unofficial and exhibit a conflict between formal and actual operational implementation. In this chapter, the use and implementation of feral systems in Denmark are analysed and discussed. It is found interesting to aim for an understanding of feral systems in a small, relatively agile economy with traditionally positive to rapid adoption of information technology in enterprises. The method being used is qualitative case studies in selected companies representing various complexities of their respective business models and industries. The case studies address both issues of organisational and technological nature of the feral systems typically with an offset in the companies’ overall information systems architecture. Among findings are (1) feral systems as a known choice when reflecting business processes with open and non-routinised character, (2) a general acceptance not related to the size or industry, (3) feral systems have received attention as implementations of innovation, (4) feral systems start as opposed to formal and official systems, but during their lifetime they can drift towards a more official status, and (5) feral systems are accepted as low-cost solutions to fill gaps in business process support where ERP systems come short.
Chapter Preview
Top

Introduction

Feral systems are regarded to be the IT users response to misfit between official enterprise information systems (EIS) and business processes in terms of making systems on their own terms (Houghton & Kerr, 2004). Posssible causal explanations that have been offered for misfits include strategic misalignment to operational issues of e.g. unsupported processes, training, information granularity, local issues, EIS lagging behind business changes, etc. (Gattiker & Goodhue, 2005). In studying optimal design of EIS related to the desired level of systems support to the business, feral systems can represent ‘gap fillers’ in non-optimal EIS design (Thatte & Grainger, 2010). Feral systems thus indicate individual and local organisational responses to optimal design of information systems. Feral systems must generally be observed as contrary to official policies, and the role of feral systems is therefore also reflecting organisational characteristics where certain activities are socially permissible although not officially approved. In understanding the organisational prerequisites for feral systems, this chapter presents and discusses a number of case studies from medium and large-sized companies in Denmark. Denmark is a small country with a very open and dynamic economy placed as number four at World Economic Forums 2012 Global IT Ranking (Dutta & Bilbao-Osorio, 2012). Danish industry is recognised by a high prevalence of businesses within the SME segment typically acting both independently and in synergy with larger national and international corporations (Multi-National Corporations - MNCs). Adoption rate of information technology (IT) in business and by consumers has for decades been among the highest in the world.

Studying feral systems is studying discrepancies between official EIS design and actual business processes (Hobson et al., 2005). As most enterprises use standard ERP software and other commercial off-the-self (COTS) business information systems software, the feral systems reflect a general inappropriateness of these products in relation to dynamics and completeness of business. Berg (1998) reflects upon the gap between designers and users of information technology, and its largely political character, where feral systems can be one of the users’ responses to this misfit. ERP systems are in the centre of these discussions, but feral systems can occur in most other information systems environments engaging technology, business and users. Behrens (2009) is analyzing a case of a Learning Management System in a university as an example of feral systems in a non-business computing environment. King (2012) describes feral or shadow systems development within sales, games and network management.

In a Danish industrial context, constant change is a key discussion where industries see themselves as constantly challenged by global competition and therefore accept ongoing changes at all levels as part of regular business. Change might be a stereotype in studying business development, and in a qualitative study there is obviously no quantitative underpinning of change rate. In this context, change is more a question of the rate of external business requirements that cannot be implemented sufficiently fast in existing EIS, thus creating constants gaps. This leads to a view of Danish companies being early adopters of relatively monolithic general ERP systems contrary to industrial environments characterised by information systems silos, islands or more dedicated information systems. This furthermore connects the entrapment described by Hanseth et al. (1996) between standardisation and flexibility in the shaping of corporate information systems’ infrastructure. The high level of adaptation from Danish companies can be seen both in the light of customer appeasement but also strong flexibility or even volatility in the upstream supply chain to suppliers. Feral systems can rapidly support new business processes, and if done by business actors, there is a strong correlation between knowledge and systems. On the other hand, the rapid and uncontrolled systems adaptation is person-bound, difficult to scale up and out, difficult to maintain, operate, document and can be overlooked when host systems are changed.

Complete Chapter List

Search this Book:
Reset