From IS to Organisation: Analysing the Uses of a

Collaborative IS in a High-tech SME

Ewan Oiry, Amandine Pascal

and Robert Tchobanian

Institute of Labour Economics and Industrial Sociology, LEST – UMR 6123

35 Avenue Jules Ferry

13626 Aix en Provence Cedex 01, France

Abstract. Researchers and practitioners generally observe a disparity in

organisations between the actual uses of HRIS and what was expected of them

prior to implementation [1]. In order to investigate this phenomenon, [7]

develops a coherent and structured conceptual framework that can be used to

analyse the reasons why actors develop such different uses for a given

technology. While our paper uses her theoretical propositions as a framework

for analysing uses, it seeks to extend her approach by means of a theoretical

framework that can be used to understand the spirit of the technology and

interactions between individuals and artefacts. Following an outline of these

various concepts (2.), a case study of the uses of a collaborative IS in a high-

tech SME (3.) will serve as a basis for an initial test of this analytical

framework (4.) and discussing the contributions it makes (5.).

1 Introduction

Since the end of the 1990’s, HRISs have crossed the borders of the HR department

and have began to impact the wider organization: senior management, line managers

and even employees [5]. HRISs are complex social objects which are the outcome of

the embedding of computer systems into an organization. The development of those

systems articulates two communities particularly different: a community of users and

a community of providers. Users are the people how are supposed to use HRIS and

providers are the systems engineers whose expertise is in designing, developing,

implementing and maintaining the information systems that the users use

Researchers and practitioners generally observe a disparity in organisations between

the actual uses of IS and what was expected of them prior to implementation [1]. In

order to investigate this phenomenon, Orlikowski [7] develops a coherent and

structured conceptual framework that can be used to analyse the reasons why actors

develop such different uses for a given technology. While our paper uses her

theoretical propositions as a framework for analysing uses, it seeks to extend her

approach in two aspects.

Oiry E., Pascal A. and Tchobanian R. (2008).

From IS to Organisation: Analysing the Uses of a Collaborative IS in a High-tech SME.

In Proceedings of the 2nd International Workshop on Human Resource Information Systems, pages 30-39

DOI: 10.5220/0001743800300039

 SciTePress

Firstly, although she acknowledges the tangible dimension of technology

(‘technology as artifact’), Orlikowski [7] does not really bring it to bear in her

analysis of uses. In order better to analyse the place that this artefact might play in the

construction of uses, we will incorporate into her framework the concept of the ‘spirit

of technology’ [3]. Secondly, it also seems to us necessary to incorporate explicitly

into her analytical framework the existence of other instruments that might influence

the uses of the IS under investigation, as highlighted in the distributed cognition

approach.

Following an outline of these various concepts (2.), a case study of the uses of a

collaborative IS in a high-tech small and medium enterprise (SME) (3.) will serve as a

basis for an initial test of this analytical framework (4.) and for discussing the

contributions it makes (5.).

2 Construction of a Theoretical Framework for Analysing the

Disparities between the Uses Expected by the Designers and the

Actual Uses of a HRIS

Orlikowski [7] takes the view that, when a technology is mobilised in a context of

recurrent social interactions, it becomes a ‘technology-in-practice’ and constitutes an

intangible form that plays a part in human actions (the repeated social interactions)

through the facilities, norms and interpretive schemes that it helps to construct. Thus

every type of use to which a technology is put shapes specific facilities, norms and

interpretive schemes that change the nature and content of the repeated social

relations that individuals develop in their work, their teams or their companies.

Orlikowski is aware that, beside the ‘technology-in-practice’, there is a formal aspect

of technology (its functionalities, for example). She even conceptualises it by

advancing the notion of ‘technology as artifact’ ([7] p.408). Nevertheless, she does

not bring this aspect into play directly in her analysis of uses. Even though uses can

never be deduced mechanically from the notion of ‘technology as artifact’ [9], it

seems to us that it does, nevertheless, play a role in the uses that are made of a

technology. It is for this reason that we extend Orlikowski’s analytical framework by

adding to it the notion of the ‘spirit of the technology’ [3], which seeks directly to

analyse how a technology has been constructed by its designers and how its principal

features influence the uses developed with it.

More specifically, the ‘spirit’ of the technology denotes general intention, goals and

values that underpin the technology. It reflects the official line of conduct to be

adopted by users and the purposes assigned to it. Thus our aim is to reincorporate into

our theoretical framework this aspect of technology (technology as artefact), which is

mentioned but not used by Orlikowski [7] in her analysis of actual uses. It seems to us

necessary to retain this concept, since certain uses can be readily explained by what

the designers incorporated into the technology during the development process.

Similarly, it seems to us that Orlikowski’s formulation of uses [7] does not make it

possible to take account of all the lessons that can be derived from studies based on

the distributed cognition approach ([6]; [4]). While we are seeking to extend

Orlikowski’s approach in a fairly simple way, it seems to us important to stress that

the uses are also constructed by the way in which this new application is integrated

into pre-existing applications and work practices.

Distributed cognition theory is, after all, concerned with the structure of knowledge,

with its transformation and its propagation by means of artefacts in a context

characterised by interaction (processes of cooperation and collaboration) among

individuals whose cognitive development is regarded not as an isolated event but as

taking place within a system in which both individuals and the artefacts they use are

participants. Distributed cognition theory emphasises the role played by the objects

present in the environment. These objects cannot be regarded as mere peripheral aids

to cognition. Rather, they constitute a form of external representation, which, together

with internal representations, plays a role in establishing the representational system

of a distributed cognitive task [8]. From this point of view, the distributed cognitive

approach seems to us a vital element of any attempt to understand uses.

3 Methodology and Case

The investigation conducted here is strictly exploratory. The phenomena under

investigation are not well known and their boundaries are ill defined. For these

reasons, the case study seems to be the most appropriate research method [11].

The case study was carried out in a software and computer services company that

produces and markets several software packages (registry/public records office

management, mail digitisation and management, document classification). In 2006,

the company’s turnover was 4.5 million euros and it employed a total of 48 people.

The workforce is distributed among 6 departments: digitisation software (10 people),

electronic data Interchange (EDI) software (7 people), customer support (10 people),

implementers (8 people), sales (10 people), administration (3 people).

In the autumn of 2007, this SME began to use the ‘think together®’ software package,

the purpose of which, according to its designers, is to ‘facilitate and accelerate

decision-making in organisations’. In order to understand the ‘spirit’ of this

technology, we conducted three interviews with the designers of the software. We

also interviewed the SME’s managing director. He told us that this software package

was intended in the first instance for use in the Electronic Data Interchange software

department. Accordingly, we interviewed more than half the members of this

department (4 out of 7). In order to extend the scope of our analysis, we also

interviewed the head of the customer support department.

4 Results: Spirit of the Technology, Uses and Environments

We draw here on the theoretical framework outlined above in order to analyse the

social structures enacted by the technology’s designers, to characterise the uses of this

software and to consider them in relation to the social, instrumental and cultural

environment in which they were produced.

In order to remain true to the approach developed by Orlikowski, we are going

systematically to characterise the uses these different actors make of the software in

terms of the ‘interpretive schemes’, ‘norms’ and ‘facilities’ that structure those uses.

We are going to see that the disparity between expected and actual uses can be

understood in terms of the disparity between the way in which the designers (41.), end

users (42.) and purchase initiator (43.) represent these uses to themselves.

4.1 A Spirit of the Technology Shaped by the Notion of ‘Organisational

Transparency’

During the interviews with the two designers of ‘think together®’, we noted that they

had a very precise idea of what seemed to them to constitute an appropriate use for

their software. From their perspective, the software is intended to enable users to

make ‘good’ decisions. For example, one of them stated: ‘The idea of [‘think

together®’] emerged in the wake of a problem we were experiencing at X [his

previous employer], namely a failure to take our opinions [as software developers]

into account, the lack of recognition for what each of us contributed to the

organisation. People were raising problems but the line manager was not taking any

notice and we were coming up against a wall … what’s more, it was us who then had

to repair the damage!’.

This representation that they constructed of the appropriate use for their software is

based on precise and coherent hypotheses as to what constitutes a good decision-

making process in a company. From their point of view, such a process is constructed

firstly by ‘soliciting the opinion of the greatest number of people in the decision-

making process’. Thus this first interpretive scheme that they incorporated into their

technology reflects the notion that increasing the number of opinions increases

creativity and ensures that the entire range of views that exist within the organisation

will have been canvassed. From their perspective, secondly, a good decision is

constructed if those involved managed to ‘bring all these different opinions to a point

of convergence’. Thus the second interpretive scheme they incorporated into their

technology reflects the need to bring this ‘seething mass’ of different ideas to a point

of convergence in order rapidly to produce a mutually acceptable solution that can

serve as a basis for decision-making.

These interpretive schemes (diversity of opinions, need for convergence) are reflected

in their representation of the appropriate use by behavioural norms, which, in turn,

structure the software package. For example, the idea that a good decision arises out

of a clash between very diverse arguments led the designers to structure the

interactions between discussants in a very precise way. An employee puts forwards a

topic for discussion

. He or she can choose the individuals to be invited to take part in

this discussion

. The members of the discussion group receive an e-mail in which the

initiator of the discussion outlines his or her point of view. They can respond to each

of the arguments advanced by clicking on four different buttons: support: to put

forward an argument that tends in the same direction as the one being advanced;

modify – to advance an argument that opposes the one being put forward; reply – to

put forward an argument that responds to a question raised by the initiator in the

course of his or her argument; propose – to advance an argument that opens up a new

topic for discussion (thus not connected with the initial discussion).

The various options contained within this behavioural norm are given concrete

expression in the software in the interface that the designers call the ‘cartography’,

which takes the following form:

The blue arrow indicates that the reply supports the preceding

statement.

The red arrow indicates that the reply is opposed to the preceding

statement.

The black arrow indicates that the response is a reply to a question

posed in the previous statement.

Fig. 1. Example of the formalisation of the discussion in the ‘cartography’.

The colours of the arrows indicate the way in which the discussion has progressed.

The designers also put in place a fairly sophisticated system of indicators that show

the percentage of people who have declared themselves for or against a particular

argument, etc. The aim of the software is also to reach a final agreement rather than

engaging in a discussion simply goes on and on. Thus from the designers’ point of

view, the example depicted below would constitute a failure for their software.

Potentially, all employees, regardless of their position in the hierarchy, have the right to

initiate a new discussion.

The list submitted to him or her by default includes all employees; the initiator chooses those

to be included in the discussion.

Topic for

discussion

Reply 1

Jean

Reply 2

Sophie

Reply 3

Jean

Reply 4

Laure

The green arrow indicates that the reply proposes a new topic for

discussion.

The other colour codes have the same meaning as those given in

Figure 1 above.

Fig. 2. Example of the formalisation of a ‘divergent’ discussion in the ‘cartography’.

The facilities the software package provides reflect the behavioural norms and

interpretive schemes assumed by the designers: in order to take a good decision, it is

necessary to consult as many people as possible. However, this has a major

disadvantage: it is difficult to make a discussion in which many actors have been

involved to converge towards a single solution. Consequently, the software has to be

equipped with facilities that help the leader of the discussion precisely to ‘plot’ the

arguments advanced by all involved in order to reach a final consensus.

4.2 A Use that Respects this Spirit while Linking Up with other Instruments

The interviews conducted in this firm that uses ‘think together®’ revealed that certain

uses do indeed seem to be of the type that the designers expected.

Thus one developer stated: ‘We’d been holding meeting after meeting for four months

in an attempt to solve a problem, namely how to link our ‘mail’ product [which

digitises incoming mail] and our ‘document’ product [which automatically classifies

documents]. Customers had been asking us for months to link the two together and we

couldn’t decide on how to do it. I gathered all the e-mails we had exchanged and fed

them all into [‘think together®’ ]. That was Friday (…) This created a stir, with

everybody giving their opinion… The Wednesday afterwards, we had a meeting and

we came out of it with a firm decision. We really unblocked the situation thanks to

[‘think together®’].’

This example shows that the structure of the ‘good decision’ that the designers

incorporated into the software may sometimes reflect the decision-making process in

an organisation. In this case, the actual use may be reasonably faithful to the spirit of

the technology incorporated into the software by the designers.

Nevertheless, this diagnosis has to be qualified on two counts. Firstly, the developer’s

statements quoted above show that, in order to analyse in detail the use he made of

‘think together®’, account has to be taken of the uses he made of the other

coordination instruments that exist in this organisation (e-mail, meetings, probably

also telephone and face-to-face discussions). After all, although ‘think together®’

demonstrated its relevance in this case, these additional instruments considerably

reduce the likelihood that this new software package will be used on a regular basis in

this organisation. After all, discussions, e-mails and meetings seem to be the

instruments most favoured by the actors in this organisation. Thus it would only be in

cases in which these instruments have failed that this user would turn to ‘think

together®’. This competition between the various instruments undoubtedly explains

some of the under-use of collaborative software in organisations. They are not much

used because other instruments that pre-existed them are used instead and are already

distributing cognition.

Secondly, it should be noted that the final decision was not taken in ‘think together®’

itself. The software was used to bring out the various opinions (which certainly

accords with the spirit incorporated into the technology by the designers), but the final

decision was taken during a meeting (and not by means of the software, as the

designers planned). This qualification is important, since it led this developer – for

whom the software had, nevertheless, been extremely useful – to declare that ‘the

interface is not clear. In fact, there’s no real need for those arrows between the

arguments, for the different colours and all that… It would be better if the arguments

were divided into those that favour one solution and those that favour a different

one… That would make it possible to summarise the arguments more rapidly in order

to start the ball rolling at the subsequent meeting…’.

This criticism seems to us interesting because it is not targeted simply at the interface

as it was designed. This user’s dissatisfaction also stems from the fact that the

interface was designed for a particular use (decision-making in ‘think together®’) that

presupposed certain behavioural norms (bringing the arguments to a point of

convergence by clearly delineating their sequencing) supported by certain

functionalities (the ‘cartography’). This is at odds with the use this actor made of the

interface (taking the decision during a meeting), which involves different interpretive

schemes (revealing opinions without seeking to achieve convergence within the

software), different behavioural norms (identification of participants’ overall position

and not the detail of each of their arguments) and thus different functionalities

(establishing broad groups of related opinions and not outlining the sequence of

arguments).

Even when the use accords fairly closely with the spirit of the technology, analysis

shows that competition from other instruments and the user’s organisational choices

(taking the decision in a meeting and not by means of the software) explain part of the

observed disparity between the expected use of the software and the use to which it is

actually put.

The case of the customer support manager also shows that the actual use may diverge

considerably from the use expected by the designers. She wanted to use the software

as a tool for collecting and pooling all the solutions already developed in order to

respond to the complex questions put by customers (FAQ). However, the use she

expected to make of it had little to do with the spirit the designers incorporated into

the technology. This other example is interesting because it provides another

explanation for the disparity between the expected and the actual uses of this

collaborative software. While being presumptively strongly in favour of this new

software, this user viewed it from the perspective of what was creating problems for

her in her work. The fact that the software had not been designed to solve this type of

problem played no part in her logic: she evaluated the software’s usefulness or

uselessness simply in terms of the use to which she wanted to put it.

4.3 The Purchase Initiator: A Singular User

Since it occupies a unique position, it seems to us important to analyse one final type

of use, namely the one represented to himself by the ‘purchase initiator’ of this

software.

We use the term ‘purchase initiator’ to denote the person who takes the decision to

purchase this software and hence to implement it within the organisation. In general,

he or she is not an end user (such as those described above). In the case we studied,

the person in question was the company’s managing director. Like the company’s

other employees, he too has the ‘right’ to initiate discussions in ‘think together®’

(which he has done, incidentally). His discourse is interesting, however, because

unlike the previous users he does not seem solely interested in the instrument’s

technical effectiveness. Whereas the other users judged ‘think together®’ in terms of

its capacity to solve problems arising out of FAQs or to unblock a jammed decision-

making process, the purchase initiator judges it in terms of its ability to change the

organisation of which he is the head.

After all, when asked: ‘Could you tell us why you decided to implement [‘think

together®’] in your company?’, he replied: ‘it’s a rather complicated story… The

Electronic Data Interchange team, which is where I wanted to use it, had not had a

manager for a long time.. We had a person, who was supposed to be the manager, but

in fact he concerned himself only with the technical side of things, he wasn’t the one

who did everything that was pure management… When he left for health reasons, we

replaced him but things turned out very badly… In terms of interpersonal relations,

the new manager was a complete failure… We had to let him go and since then I’ve

been in charge of this team… But I’ve got too many things to do and I can’t devote

enough time to them. What’s more, on the technical level, I’m not knowledgeable

enough about what they’re doing. Everything changes too quickly. There’s someone

in the team, X, who you’re going to meet, that I would like to promote to manager. I

think he has the strength of character and the abilities, but he has to mature

gradually… To my way of thinking, the use of [‘think together®’] could help him take

on this new role’.

The statements of this ‘purchase initiator’ recall a situation already encountered in

other organisations [2]. Like other users, purchase initiators position their uses of an

instrument relative to the problems they encounter in their work. For this MD, the aim

is to identify a manager for his Electronic Data Interchange software group and to get

him accepted by the team. This manager’s principal role is to foster professional

cooperation within the team (its community of practice aspect) and functional

coordination with the other departments when decisions have to be taken collectively.

The MD is using [‘think together®’] in the hope of being able to provide the future

manager with a tool to help in carrying out his duties as well as legitimation for his

managerial role.

This use accords fairly well with the initial spirit of the technology (organising

exchanges of ideas with this software equates to a standard managerial activity). It is

reinforced by the converging use of other available coordination tools (for example,

this same X has been entrusted by the MD with leading the ‘Friday’ team meetings

and his work means he is positioned at the interface between the EDI group and the

other departments in the company). However, the purchase initiator does not evaluate

the software’s contributions solely in relation to the decisions it helps to make (which

is officially why it was purchased and developed) but primarily in terms of its ability

to bring about organisational change. Now the designers developed this software

around the notion of ‘organisational transparency’, which can be practised in various

formal hierarchical organisations, in so far as they can maintain such transparency. In

this case, this ‘transparency’ was being sought by the purchase initiator in order to

legitimate a particular choice of hierarchical organisation. Thus these issues of

organisational change (which are not explicitly included in the designers’ offer)

emerge as an important factor in the disparity between the uses anticipated by the

purchase initiator and the actual uses to which the software is put by the other users.

5 Discussion

Three conclusions can be drawn from these initial results derived from the theoretical

framework outlined above:

Firstly, in line with the studies by De Sanctis and Poole [3], our case study shows that

the developers of the software designed it with a clear idea in their heads of the type

of use to which it should be put, a use inferred from the social structures they were

enacting. The functionalities they built into their software show how they

incorporated their representation into the software itself. Thus, like Orlikowski [7],

we maintain that the social structures are not embedded in the technology.

Nevertheless, these structures enacted by the software designers may influence future

uses and must therefore be included in the analysis. Consequently, we have put

forward in this article some proposals concerning the status that a technological

artifact might have in an analysis of use such as that proposed by Orlikowski.

Secondly, the actual uses that the employees in this company have made of the

software may or may not accord with the spirit of the technology. This is in line with

Orlikowski’s findings [7], which show that, in developing a technology, designers

construct a vision of the world and then retranscribe it in the form of technological

properties and that, when users engage recursively with the technology, they develop

a technology-in-practice that may diverge considerably from the developers’

intentions. If they are to be correctly analysed, however, these intentions must be

repositioned relative to the groups and instruments already in existence in the

organisation, as advocated by the distributed cognition school.

Finally, our results lead us to highlight the role of a particular actor, namely the

person who introduced the software into the organisation and whom we have

described as the purchase initiator. We have shown that the use of this software that

he wanted to see implemented is not confined to improving existing decision-making

processes but extends to an expectation of change in the organisation itself (towards

greater interdepartmental cooperation). Since this actor expresses most accurately in

his actions the actual uses to which this new software is put, this might cause him to

minimise the actual contributions made by the software, even if they are fairly

consistent with the original motivation behind the software, as soon as those uses fail

to bring about the organisational changes he is seeking.

References

1. Bowers, J.(1995). Making it work. A field study of a CSCW Network. The Information

Society, 11, 189-207.

2. D’Iribarne A., Lemoncini S., Tchobanian R. (1999), Les outils multimédia en réseau

comme supports à la coopération dans l’entreprise : les enseignements d’une étude de cas

(Multimedia tools on line as supports for cooperation in the firm: the findings of a case

study, Proceedings of the 2

International Conference on Uses and Services in

Telecommunications (ICUST), Arcachon, 7-9 Juin.

3. DeSanctis G., Poole S., (1994). Capturing the complexity in advanced technology use:

Adaptive structuration theory. Organization Science, Vol. 5, Nù2, pp. 121-147.

4. Hutchins E., (1995). Cognition in the Wild, Cambridge, MA MIT Press.

5. Magalhaes R., Rüel H. (2007). Engineering the Organization for People Management, CfP

of 2nd International Workshop on Human Resource Information Systems, Barcelona.

6. Norman D., (1991). Cognitive artifacts. In Desiging Interaction, Psychology at the human

Computer Interface, (ed.) J.M. Carroll, Cambridge Series on Human Computer Interaction,

Cambridge University Press.

7. Orlikowski W., (2000). Using technology and constituting structures: a practice lens for

studying technology in organizations. Organization Science, Vol. 11, Nù4, pp.404-428.

8. Salembier P., (1996). Cognition(s) : située, distribuée, socialement partagée

… (Cognition(s): situated, distributed, socially shared) Bulletin du LCPE, École Normale

Supérieure, Paris.

9. Strohmeier, S. (2006). Coping with contradictory consequences of e-HRM, Proceedings of

the first academic workshop on e-HRM research, Twente, 25-26 October.

10. Swanson EB., Ramiller NC. (2004), « Innovating mindfully with information technology »,

MIS Quarterly, Vol 28, n°4, pp. 553-583.

11. Yin, R.K. (1994) Case Study Research : Design and Methods, London, Sage.