3organisational needs) and ‘integration’ (with existing information infrastructures).
1
Yetthis is no longer the case. We conducted research on a world leading global softwarevendor. Crucially, whilst it receives hundreds of thousands of requests for help everyyear, today, and, in stark contrast to the situation a few years ago, only a very smallnumber of these now require localist forms of support. Instead, the bulk of users receivehelp remotely, through a virtualised medium, in which support staff rarely (if at all)meet with the users of failing systems, have little or no specific knowledge of their localsite, and interact with them through a restricted channel.
2
Moreover, not only areproblems seldom dealt with locally, but also they are resolved through the so-called‘follow the sun’ (Aneesh 2006) approach. Failing systems are worked on remotely inone office and when those experts go home for the night, the problems are passed toother staff in a different time zone. This produces two important results: failures receiveimmediate and constant attention
wherever
and
whenever
they arise; but it also commonfor less tractable problems to have travelled the world (and been worked on by manydifferent teams) before a satisfactory resolution is found.
3
Clearly we are dealing with forms of practice different from the ones theorised by Orrand others a decade or so ago. Technical support has arguably been recast and insertedin a new geographical and temporal regime. This has implications for how sociologistsconceptualise the nature of technical support as well as the space and time in which itoccurs. Importantly, however, current social science approaches do not handle as wellas they might these post local forms of practice. Through the term ‘post local’ we referto important shifts occurring in
how
,
when
and
where
technical problems are managedand resolved. In particular, focusing on this last aspect, the general aim of the article isto moves away from a view of repair revolving exclusively around the situation as a‘small place’. Rather, as support work is increasingly ‘stretched out’ (Nicolini 2007), it
1 The vast (and still growing) academic and practitioner literature on enterprise systems reveals ample evidence of the the variousdifficulties users experience whilst attempting to implement these kinds of systems and how they often experience problems and‘crashes’(Gable 2001; Hirt and Swanson 2001; Jansen et al. 2006).2 The vendor states, and we have no reason to doubt this claim, that whilst it receives in excess of 800,000 calls for help each year,only 500 or so require a support specialist to actually to travel out to visit a site (SoftCo presentation). In other words, the vastmajority of complex technical failures are managed, diagnosed and resolved remotely.3 We do not think our case is unusual – many of the larger software providers have moved, or are attempting to move, technicalsupport online (see for instance Orlikowski [1996] who discussed an early attempt by one firm to automate and formalise the repairof software).
Add a Comment