The Case of Zeta


Zeta is one of the top fifty software companies in the United States, with $100 million in revenues and about 1,000 employees. It produces and sells a range of powerful software products that provide capabilities such as decision support, executive information, and marketing analysis. Zeta is headquartered in the Midwest, with sales and client-service field offices throughout the world.

Specialists in the customer service department (CSD) at Zeta provide technical support via telephone to clients, consultants, value-added resellers, Zeta clientservice representatives in the field, and other Zeta employees who use the products. This technical support is often quite complex. Specialists typically devote several hours of research to each problem, often searching through reference material, attempting to replicate the problem, and reviewing program source code. Some incidents require interaction with members of other departments such as quality assurance, documentation, and product development. The CSD employs approximately fifty specialists and is headed by a director and two managers.

In 1992, the CSD purchased the Lotus Notes groupware technology within which it developed a new incident tracking support system (ITSS) to help it log customer calls and keep a history of progress toward resolving customers' problems. Following a successful pilot of the new system, the CSD decided to commit to the Notes platform and to deploy ITSS throughout its department. The acquisition of new technology to facilitate customer call tracking was motivated by a number of factors. The existing tracking system was a homegrown system that had been developed when the department was much smaller and Zeta's product portfolio much narrower. The system was not real-time, entry of calls was haphazard, information accuracy was a concern, and performance was slow and unreliable. It provided little assistance for reusing prior solutions and no support for the management of resources in the department. The volume and complexity of calls to the CSD had increased in recent years due to the introduction of new products, the expanded sophistication of existing products, and the extended range of operating platforms supported. Such shifts had made replacement of the tracking system a priority, as the CSD managers were particularly concerned that the homegrown system provided no ability to track calls, query the status of particular calls, understand the workload, balance resources, identify issues and problems before they became crises, and obtain up-to-date and accurate documentation on work in progress and work completed. In addition, calls would occasionally be lost, as the slips of paper on which they were recorded would get mislaid or inadvertently thrown away.

Introduction of ITSS

The initial introduction of the new ITSS system was accompanied by anticipated changes in the nature of both the specialists' and managers' work. In contrast to the previous system, which had been designed to capture only a brief description of the problem and its final resolution, ITSS was designed to allow specialists to document every step they took in resolving a particular incident. That is, it was designed to enable the capture of the full history of an incident. As specialists began to use ITSS this way, the focus of their work shifted from primarily research—solving problems—to both research and documentation—solving problems and documenting work in progress.

The ITSS database quickly began to grow as each specialist documented his or her resolution process in detail. While documenting calls took time, it also saved time by providing a rich database of information that could be searched for potential resolutions. Moreover, this new database of information served as an unexpected, informal learning mechanism by giving the specialists exposure to a wide range of problems and solutions. As one specialist noted: "If it is quiet, I will check on my fellow colleagues to see what kind of calls they get, so I might learn something from them just in case something might ring a bell when someone else calls". At the same time, however, using the ITSS database as a sole source of information did pose some risk because there were no guarantees of the accuracy of the information. To minimize this risk, the specialists tacitly developed informal quality indicators to help them distinguish between reliable and unreliable data. For example, resolutions that were comprehensively documented, documented by certain individuals, or verified by the customer were considered reliable sources of information.

In addition to these changes in specialists' work, the CSD managers' use of the new system improved their ability to control the department's resources. Specialists' use of ITSS to document calls provided managers with detailed workload information, which was used to justify increased headcount and adjust work schedules and shift assignments on a dynamic and as-needed basis. ITSS also supplied managers with more accurate information on specialists' work process, for example, the particular steps followed to research and resolve a problem, the areas in which specialists sought advice or were stalled, and the quality of their resolutions. As managers began to rely on the ITSS data to evaluate specialists' performance, they expanded the criteria they used to do this evaluation. For example, quality of work-in-progress documentation was included as an explicit evaluation criterion, and documentation skills became a factor in the hiring process.

Structural Changes

As the CSD gained experience with and better understood the capabilities of the groupware technology, the managers introduced a change in the structure of the department to further leverage these capabilities. This change had not been planned prior to the implementation of ITSS, but the growing reliance on ITSS and an appreciation of the capabilities of the groupware technology created an opportunity for the CSD to redistribute call loads. In particular, the CSD established "first line" and "second line" support levels, with junior specialists assigned to the first line, and senior specialists to the second line. The CSD created partnerships between the less experienced junior specialists and the more experienced senior specialists. Frontline specialists now took all incoming calls, resolved as many as they could, and then electronically transferred calls to their second-line partners when they were overloaded or had especially difficult calls. In addition to handling calls transferred to them, senior specialists were expected to proactively monitor their frontline partners' progress on calls and to provide assistance.

While this partnership idea was conceptually sound, it regularly broke down in practice. Junior specialists were often reluctant to hand off calls, fearing that such transfers would reflect poorly on their competence or that they would be overloading their more senior partners. Senior specialists, in turn, were usually too busy resolving complex incidents to spend much time monitoring their junior partners' call status or progress. In response to this unanticipated breakdown in the partnership idea, the CSD managers introduced another opportunity-based structural change. They created a new intermediary role that was filled by a senior specialist who mediated between the first and second lines, regularly monitored junior specialists' call loads and work in progress, and dynamically reassigned calls as appropriate. The new intermediary role served as a buffer between the junior and senior specialists, facilitating the transfer of calls and relieving senior specialists of the responsibility to constantly monitor their frontline partners. With these structural changes, the CSD in effect changed the prior undifferentiated, fixed division of labor within the department to a dynamic distribution of work reflecting different levels of experience, various areas of expertise, and shifting workloads. In response to the new distribution of work, managers adjusted their evaluation criteria to reflect the changed responsibilities and roles within the CSD.

Another change that emerged over time was a shift in the nature of collaboration within the CSD from a primarily reactive mode to a more proactive one. Because all specialists now had access to the database of calls in the department, they began to go through each others' calls to see which ones they could help with, rather than waiting to be asked if they had a solution to a particular problem (which is how they had solicited and received help in the past). This shift from solicited to unsolicited assistance was facilitated by the capabilities of the groupware technology, the complex nature of the work, existing evaluation criteria that stressed teamwork, and the long-standing cooperative and collegial culture in the CSD. Several specialists commented: "Everyone realizes that we all have a certain piece of the puzzle.I may have one critical piece, and Jenny may have another piece.If we all work separately, we're never going to get the puzzle together. But by everybody working together, we have the entire puzzle"; "Here I don't care who grabs credit for my work.This support department does well because we're a team, not because we're all individuals".[10] Managers responded to this shift in work practices by adjusting specialists' evaluation criteria to specifically consider unsolicited help. As one manager explained: "When I'm looking at incidents, I'll see what help other people have offered, and that does give me another indication of how well they're working as a team".

Later Changes

After approximately one year of using ITSS, the CSD implemented two further organizational changes around the groupware technology. Both had been anticipated in the initial planning for ITSS, although the exact timing for their implementation had been left unspecified. First, the ITSS application was installed in three overseas support offices, with copies of all the ITSS databases replicated regularly across the four support sites (United States, United Kingdom, Australia, and Europe).This provided all support specialists with a more extensive knowledge base on which to search for possibly helpful resolutions. The use of ITSS in all the support offices further allowed specialists to transfer calls across offices, essentially enacting a global support department within Zeta.

Second, the CSD initiated and funded the development of a number of bugtracking systems that were implemented within groupware and deployed in Zeta's departments of product development, product management, and quality assurance. These bug-tracking applications were linked into ITSS and enabled specialists to enter any bugs they had discovered in their problem resolution activities directly into the relevant product's bug-tracking system. Specialists could now also directly query the status of particular bugs and even change their priority if customer calls indicated that such an escalation was needed. Specialists in particular found this change invaluable. For the other departments, the link with ITSS allowed users such as product managers and developers to access the ITSS records and trace the particular incidents that had uncovered certain bugs or specific use problems. Only the developers had some reservations about the introduction of the bug-tracking application—reservations that were associated with the severe time constraints under which they worked to produce new releases of Zeta products.

In addition to the improved coordination and integration achieved with other departments and offices, the CSD also realized further opportunity-based innovations and emergent changes within its own practices. For example, as the number of incidents in ITSS grew, some senior specialists began to realize that they could use the information in the system to help train newcomers. By extracting certain records from the ITSS database, the specialists created a training database of sample problems with which newly hired specialists could work. Using the communication capabilities of the groupware technology, these senior specialists could monitor their trainees' progress through the sample database and intervene to educate when necessary. As one senior specialist noted: "We can kind of keep up to the minute on their progress.If they're on the wrong track, we can intercept them and say, ‘Go check this, go look at that.’ But it's not like we have to actually sit with them and review things. It's sort of an on-line, interactive thing". As a result of this new training mechanism, the time for new specialists to begin taking customer calls was reduced from eight weeks to about five.

Another change was related to access control. An ongoing issue for the CSD was who (if anybody) outside the CSD should have access to the ITSS database with its customer call information and specialists' work-in-progress documentation. This issue was not anticipated before the acquisition of the technology. While the managers were worried about how to respond to the increasing demand for access to ITSS as the database became more valuable and word about its content spread throughout the company, they continued to handle each access request as it came up. Over time, they used a variety of control mechanisms ranging from giving limited access to some "trusted" individuals, generating summary reports of selected ITSS information for others, and refusing any access to still others. As one manager explained, only after some time did they realize that their various ad hoc responses to different access requests amounted to, in essence, a set of rules and procedures about access control. By responding locally to various requests and situations over time, an implicit access control policy for the use of ITSS evolved and emerged.

[10]Orlikowski 1995.




Inventing the Organizations of the 21st Century
Inventing the Organizations of the 21st Century
ISBN: 026263273X
EAN: 2147483647
Year: 2005
Pages: 214

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net