SURGIMIENTO DEL ACOMPAÑAMIENTO TERAPÉUTICO 58

2.6.1 Intermediation in the Packaged Software Supply Chain

The packaged software market has been described as a prime target for disintermediation. Giaglis et al. (2002) argue that given the dominance of companies such as Microsoft, intermediaries have struggled to differentiate themselves in order to attract customer. However, the software product market exists in part because of the participation of other non software-vendor participants (Sawyer, 2001). Included

here are consulting groups, system integrators, trainers and other software producers. These intermediaries facilitate the linkage between software purchasers and producers because vendors often minimise their role in implementation. A dominant goal of software vendors is to sell their products, leaving it to others to implement them in consumer organisations (Sawyer, 2001). Intermediaries may even sell the vendor’s products on their behalf (sometimes also referred to as vendors, or as resellers). Moreover, these intermediaries may also sell their own services such as consultancy to assist with finding a product and implementing it, support services, customisations and bolt-on products. The software product market therefore gives rise to a software services market. The intermediaries that comprise this market can thus, also affect selection processes.

In contrast to custom approaches where close links between users and developers are considered critical (Flynn and Davarpanah Jazi, 1998; Peppard, 2001), software purchasers and developers use a variety of mediated means to communicate. Some of these links are shown in Table 2.1. Although these links may be necessary for the functioning of the packaged software market, they can represent a barrier between end users and developers. This point clearly made in the previous section where even large organisations did not necessary have all of their requirements satisfied. Moreover, even where direct contact does occur (the preferred kind of link according to Keil and Carmel (1995)), it may be that those involved in the link are unable to convey requirements and interpret them (again as with custom development (Curtis et al., 1988; Flynn, 1998; Lai, 1998). The dynamics of purchaser-vendor links are important considerations in packaged software selection as they give an indication of a consumer organisation’s opportunities for influencing the development trajectories

of vendors and how they might deal with other matters, such as support, post purchase.

Table 2.1: Customer-Developer Links in Packaged Software Development Adapted from: (Keil and Carmel, 1995)

Link Support line Survey User-interface prototyping Requirements prototyping Interview Testing Email/bulletin board Usability lab Observational study Marketing and sales User group

Trade show Focus group

Description

A unit that helps customers with day-to-day problems Textual surveys administered to a sample of customers

Customers are exposed to a demo, or early version, to uncover user-interface issues

Customers are exposed to a demo, or early version to discover system requirements

One-on-one with end-user; open-ended or semi-structured New requirements and feedback stemming from testing

Customers post problems, questions, and suggestions electronically

Specially constructed labs for taping and measuring user subjects at work.

Customers are followed for an extended period to learn what they do

Representatives meet current and potential customers to obtain requirements

Customer groups convene periodically to discuss software usage and improvements

Customers are exposed to mock-up or prototype and asked for feedback

A small group of customers are brought together to discuss the software

2.6.2 Relationships Amongst Vendors, Implementation Partners and Purchasers

There is a co-dependent relationship amongst vendors, intermediaries and purchasers. Organisations enter into long-term relationships with packaged software vendors. They do not want to customise software and so they need to become active in user groups, a mechanism by which software buyers collectively try to influence

the vendor's plans for package maintenance and enhancement (Markus and Tanis, 2000). Conversely, the packaged software vendors need customers to buy their products. In addition, it is possible to highlight links between vendors and intermediaries. This is often based on the exchange of information about products, services and market conditions. In cases where an intermediary has contact with customers, a vendor may not be able to offer services such as new versions of products without their assistance. If the vendor bases his range of products/services and products and services from the intermediary then a corresponding dependency relationship arises (Andersson and Nilsson, 1996). Therefore, it is also possible to highlight a co-dependent relationship between vendors and intermediaries. Intermediaries help the consumer organisation in a number of ways and this is their reason for being in business. Unsurprisingly, these relationships amongst purchases, vendors and intermediaries can be fraught with difficulties.

Consultants may offer standard solutions to problems that are very specific to the organisations that are employing them – they may not want, or be able to, grasp specific organisational realities. Consultants may also be viewed as holding too much power, influence and knowledge which may ‘walk out of the door’ when they do (Skok and Legge, 2001). In one ERP project, the company reported that the documentation provided by the consulting group was not tailored to their needs. For example, a costing invoice was called a ‘different outlet’ which did not make much sense to their employees (Skok and Legge, 2001). In contrast, Guilbert looked into the use of intermediaries to facilitate their ERP implementation process. However, the management team decided that it was preferable to use internal expertise to enable change management and thus, consultants only used to assist in the technical

configuration of the software (Gibson et al., 1999). However, adopting the solution of training a company’s internal staff is only slightly less risky. Employees with experience of packages that are in high demand are often lured away by other organisations who wish to implement the same one (Martin, 1998).

As packaged software is a generic product, popular products may see overwhelming demand for implementation and this may lead to a dearth of support for selection and implementation. The ERP market in the late 1990s is a good example. The ERP market grew so quickly that this led to a shortage of competent consultants (Bingi et al., 1999; Sumner, 2000). Purchasing organisations therefore widely complained about consultants with only a few months training who charge US$ 2,500 a day (Martin, 1998). This further manifested itself in a widespread lack of knowledge

about the details of ERP products, particularly where integrations and

partner products were concerned (Markus et al., 2000). This issue is not new, nor ERP specific. An earlier packaged software study reported difficulties in engaging users in the implementation process as the development team were perceived by the users as not possessing adequate knowledge of the product in question (Lynch, 1984).

Agenda differences have also been identified. In one study ‘Company D’ found that their consultants also wanted to get the ERP project completed as quickly as possible. It transpired that they could see a glut of business opportunities on the horizon (Skok and Legge, 2001). Differences in agendas may be further amplified and complicated where multiple vendors are involved due to the existence of

multiple packages and custom components as in ‘Best of Breed’ implementations (Light et al., 2001; Stefanou, 2001).

Finally, when a consumer organisation has entered into an agreement with a particular software vendor there may be a problem of path dependency. This is closely connected to lock-in, whereby once implemented it becomes very difficult (because of huge switching costs) to select an alternative (Howcroft and Light, 2002). Consumer organisations are effectively committing themselves to upgrading software periodically (and mostly at the behest of the developer) if they hope to avoid major conversion headaches (Markus and Tanis, 2000). Indeed, the hidden costs of support, training, tailoring, maintenance, hardware adjustment, forced upgrade and incremental licensing agreements were bemoaned by 33 per cent of respondents in one study (PriceWaterhouse, 1996). Lock-in and switching costs may also become a problem if the vendor an organisation has purchased from drops out of the market. It has been argued that, due to the relatively low costs of entry into the industry, the financial stability of some vendors is questionable and a cause for real concern (Gross and Ginzberg, 1984).