Itech software engineers as well as their technical manager dealt with this tight
situation by projecting the translation of GovIndian work practices into software codes as impossible due to “system limitation”. At this point in time, the Itech engineers as well as the GovIndian user employees interpreted system limitation as the technical constraints that made it impossible to either automate or translate organizations existing work practices into software codes. For example, see an excerpt from the conversation between Itech’s technical manager (TM) and a set of GovIndian employees:
TM: In your Flicker (the existing IS), you can straight away code into the database according to your needs. But this technology is Linux based web system (as opposed to Window based), more complex, and entirely different. In our technology, the code has to go from the screen to the EJB, from EJB to hypernet, and then to strut. I have
to automate all these links and then only I can connect to the application server.
Through application server, I have to send it to the database server. That is what I need. This is neither client server nor window-based with which you guys are
familiar. In client server, you can do any program, you can bring in any procedure, any flexibility you can make, and you can automate anything. In our system, nothing is possible that way. To do that, we have to completely change the technology.
The same point came up in my interview with Itech’s business manager:
“You go select table, everything comes here, this is their (GovIndian employees) understanding. They think that this system is like their existing systems. This system is totally different. It has its own limitation that we can do nothing. That is what we have been educating them. They are getting it bit by bit.”
This ‘education of the users’ continued during the interaction between Itech engineers and GovIndian employees. During this stage I observed fifteen such instances of
‘educating’. Below is a representative example.
This is from the discussion regarding modifying the ERP in order to meet GovIndia’s existing purchase procedure. According to the existing procedure, the indenter would take the purchase folder that contained indent for the item to be purchased, the detailed description of the items, and the approval note of each superior in the chain (it can go up to the MD) through 22 steps of approval, to hand it over to the purchase manager.
Once the suppliers quote their price, for the technical comparison of the products and the clarifications about technical specifications, the file will go from the purchase manager back to the indenter. Thus, there is a reverse flow. The Itech engineers were not ready to code this reverse flow. Instead, they suggested that the Purchase
department print out the hard copy of all documents (since there is no internet or intranet available in GovIndia) and send it manually to the indenter. It was not
possible for the indenter to take print out at his or her end since the software engineers
did not want to give access rights to the indenter. Giving access rights to indenter would have complicated the access right structure of the software. Now, see a part of the discussion between MIS, Assistant Managers (AM), and Itech Engineers (AE):
AM1: But, why is the reverse flow not possible?
AE1:Sir, the software will not allow us to do that.
MIS: Can you please explain?
AE2: Sir, you know, this is a java based multi tier program. Once you commit the event of ordering (Purchase Order) into the database, you cannot change it. If you really want to change, you will have to change the database design and then you will have to change the connection to EJB and the logic in the EJB. It amounts to almost adopting a new technology. We can do these things easily in Windows but not in this software.
AM2: But, then why can’t you at least give the access right to indenters? Isn’t it possible sir (to MIS)?
MIS: Rani, that will lead to so many other problems. These boys are right. In web based program we have a lot of limitations. So we have to understand such technical limitations and accept them as such, I think.
Finally, the technology was kept intact, not coding in the reverse flow. The implication was that the manual content of the work--an office assistant carrying purchase folder to the indenter and taking a print out that was not necessary--remained unchanged. This was against the expectation of employees that ERP would lead to significant automation, and in turn, reduction of their manual work content. See another example from a discussion between a senior engineer (SE) and Itech engineer (IE1) during testing of mechanical utility. The user asked for a search utility for finding cylinder number.
SE: “It should be a simple program. Even in excel we can do it”
IE1: ‘Sir, this is a database based program. You can’t change so easily as you do with excel. It has its own limitations. Also, you have to decide beforehand. There is a procedure that you made. If you want, you can modify. But you have to finalize and give us the final one. Then we can try, but I cannot assure you that it is possible.
System may not allow it”.
The discourse around the system limitation and technical constraints embodies a clear message that the technology has its own objective existence independent of the
developers and users of the technology, and such complex existence limits the extent of customization and automation. In other words, Itech employees had been trying to give a new sense of technology to GovIndian employees using a technology frame that depicted the ERP as a complex software independently (of its developers and users) existing that limits the extent of customization. Thus, the Itech engineers employed this technology frame to ‘mobilize sensegiving discourses’ (Spicer, 2005) that would influence other actors’ interpretation of technology and associated change.
Since such discourses had an intentional purposive goal (influence others’
interpretation), it is strategic in nature (Child, 1972). Such sensegiving discourses are not simply a reproduction of the actors’ sensemaking. For example, as Itech’s software engineers expressed in an interview, they knew that if they had put more efforts into modifying the technology, it would have been possible to avoid the manual content of the purchase order processing job and encode the reverse flow. But perhaps for the sake of convenience, the software engineers chose to attribute the cause of difficulty to the nature of the software as opposed to so many other plausible reasons, such as lack of the engineers’ knowledge and skill, and time pressure from the MD. At least with some engineers it was not a convenient expression of their sensemaking, but an intentional political choice. For example, see an excerpt from my interview (I) with an Itech Engineer (AE) regarding the reverse flow issue.
I: Yes, I see your point of the issue of difficulty in reversing the DB commitment. I also understand your difficulty to deal with the event triggers in this case. But, as per your tier structure, the data have to flow from EJB through the strut interface to the DB server, right?
AE: Yes
I: Then, why can’t you stop the commitment to DB at the strut validation? It may be
possible if you create an interface logic in the strut layer that would sit between the EJB server and the strut layer, I guess. Also, writing exceptions to event handler might help.
AE: (a long pause) Sir, I don’t really mean that it is impossible. What you suggest seems possible. But, unless I try it out, am not sure. The issue is actually none of these. Promise not to tell anyone, sir. See there are many things. We are fresh and our experience is limited. The seniors (the experienced Itech engineers who resigned) have not left any documentation and so we don’t know much about how they built the architecture or they designed the database. Those guys do not respond to our queries now. Also, we are not given enough time to explore creative solutions, rather are time pressured. Then what can you do? You have to present it such that it hurts no
one….Then, we sometimes highlight the technical constraints and system limitations to the users. This is what KK (Itech’s technical manager) also did, you see.
Therefore, the use of technology frame as a discursive device for mobilizing sensegiving discourses could be both strategic and political. If it is strategic (or purposive), what is the purpose such sensegiving discourses serve? It is obvious from the data I presented that the logic such discourses embodied was ‘system limitation’ or
‘technical constraints’. Therefore, such discourse was an attempt to create a perception among the users about what technology cannot do.
The human-computer interaction literature discusses the notion of “perceived
affordance” (Norman, 1988; 1999) as a user perception of the capability and usability of material objects. “Perceived affordance” is built upon the concept of “affordance”
(Gibson, 1979) that originated in social psychology. Norman (1988:9) defines perceived affordance as perceived properties and capabilities of the material object.
Recently, Hutchby (2001) extended the notion of affordance to technology
development and coined the term “technology affordance”. Some scholars have used the term “perceived technology affordance” to denote how users perceive the usability or capabilities of technology (e.g., Gaver, 1991) including ERP software (e.g.,
Nandhakumar, Rossi, & Talvinen, 2005). Since perceived technology affordance is users’ perception of what technology affords (or capable of) (Gaver, 1991), it is
possible to define “perceived technology non-affordance” as users’ perception of what technology cannot afford or what technology is not capable of. Therefore, we can translate the purpose of the sensegiving discourses of Itech employees as trying to influence the perceived technology non-affordance of the users, GovIndian employees.
That means the system professionals’ (e.g., Itech’s software engineers and technical manager) expert power operates through mobilizing sensegiving discourses that attempts to create certain perceptions of technology non-affordance in users. We will see this mode of exercise of system professionals’ power again during another stage well as in the following case study of WestIndia’s ERP implementation. I discuss the significance and implications of this new concept “perceived technology
non-affordance” later in the discussion part.
5.6 Stage 3: From exhaustive automation to partial automation -ERP a partially