Socio-Technical Design of Knowledge Work - Essay Example

In “Socio-Technical Design of Knowledge Work & IT – A Case Study”, Bert Painter presents a detailed and relatively balanced picture of a major system change: from a paper-file-based traditional system to a modern, networked image- and data-sharing collaborative information architecture. In Painter's depiction of the implementation of the E-File System for the Workers' Compensation Board (WCB) of the Canadian province of British Columbia we can see many of the typical challenges faced in computer rising and re-engineering traditional business processes. One of the advantages that WCB enjoyed in this process was that there was excellent motivation not only to computerize the current operation, but to reengineer the entire process of receiving, evaluating, and administering work-related injury claims. In the years leading up to the decision to create the new system, the level of service provided by the WCB had declined -- in early 1994 it was taking 45 days, on average, to process a claim. Employers were complaining of high and rising costs, and at some time in early 1994 a "service failure" (which Painter does not describe) took place. Since inertia and the implicit assumption that what works adequately cannot be significantly improved our frequent impediments to thorough process reengineering, the fact that the old process had clearly broken down was, perversely, an asset to WCB management. At the same time, there were all the usual impediments to computerizing an organization that had been muddling along with its old systems for many years. Employees were worried that they would become unemployed, "replaced by a computer". Many were frightened by new technology; we must remember in this context that in the mid-1990s far fewer people owned and used home and office desktop computers than is the case today. Workers at all levels, who had achieved a high comfort level with their old work habits and procedures, were reluctant to make major changes in how they did their jobs, and indeed in what jobs they did. Finally, some previous "false starts" in implementing new computer systems had created a degree of skepticism and impatience regarding computerization projects. At the outset of the project, WCB management, in cooperation with the WCB employees' Union, outlined a set of three broad and consensual goals for reengineering WCB's claims-processing operation: First, client service was to be improved, both in terms of timely claims processing and also in terms of quick and accurate response to client queries. Second, the new system and work processes should save the WCB money by improving workflow and productivity, by providing better cost-management information, and, it was hoped, by reducing the duration of short-term disability payments. Third, the new regime should improve the WCB work environment, allowing employees to enhance their skills and reducing such stultifying activities as paper filing. These "three pillars" were clearly chosen in order to enlist support for the project from all stakeholders, internal and external. WCB management, employees, and clients would all come out ahead. A number of mechanisms were created in order to realize the goals outlined in the "three pillars". Employees were guaranteed employment and salary protection, although management reserved the right to change workers' job responsibilities. A Technology Change Forum (with Painter as facilitator), meeting once or twice each month, was instituted for proactive information sharing and problem solving. Coordination was established among the multiple teams involved in the design and implementation of the new system and procedures; and worker participation in the design process was strongly encouraged at all stages. One of the challenges faced in implementing this project was that nobody really knew exactly how the old process worked. There was no pre-existing business process map, and idiosyncratic processes had evolved over time. At the same time, perhaps as a result of the previous "false starts" in computerizing WCB operations, there was little really mess to do a detailed analysis of business processes at the beginning of the E-File project. This meant that many of the system's requirements would not become apparent until after much of the system had already been built and at least partially implemented. As a first stage in computerizing WCB operations, a "proof of concept" system was built using off-the-shelf components: the DOX document-image management system and the workflow organizing tool FlowWare, plus some additional "bolt-on" components for interfacing to the legacy mainframe system and so on. This system was implemented in a single office in the Vancouver suburb; employees were given the option to move to another office if they did not want to participate in the pilot, but most chose to remain and to participate. To encourage these employees to take a positive view of the project, they were taken on a visit to a paperless claims office across the border in Washington State; they are described as having been "awestruck" at what they saw there. It turned out, however, that this initial system was far from adequate to meet the requirements of the WCB and its workers; the tools used simply had not been designed for this purpose. Fully 20% of staff time was devoted to such activities as filling out change requests. While in some ways the "proof of concept" system was a failure, it actually played a very positive role in the overall development process: employees developed and deepened a culture of participation in the design and development process, and a great deal was learned about what new systems and procedures really needed to accomplish. After some months, it was decided that there was no point in putting further effort into improving the "proof of concept" system; no amount of tinkering would enable it to meet requirements. Instead, a custom-developed E-File system, largely a rewrite of the DOX system, would incorporate what had been learned in the previous phase of the project. In order to guide developers, a Business Users' Group was set up to create "wish lists" of desired features. Members of this group -- "BUG's" -- would continue to be closely involved in formulating requirements, creating test cases, and in training workers during the project rollout phase. In the course of system development, it became apparent that developers and users tended to "speak different languages". Users eventually learned to provide more detail in their requests to developers; and developers -- most of whom had not previously been involved in a development project of this magnitude -- learned to provide users with more prototypes and "sketches" before coding. The new system resulted in massive changes in how WCB workers operated. Traditional jobs such as File Clerk disappeared entirely or almost so; and a new, multi-functional job, the Client Service Representative, was created. Those who became Client Service Representatives had a large part in defining the responsibilities of the new job. Changes were also made in what was done where; many functions were consolidated from 17 Service Delivery Locations to four new regional centers. As the new system was rolled out to all WCB offices, it proved to be a powerful enabler of collaboration. As will be seen, this had both positive and negative implications. Facilitated by the new E-File system, one Area Office participated in an organizational design experiment to expand the WCB’s function to include involvement with injured workers’ rehabilitation processes. When these new functions were accepted organization-wide, however, the E-File system could not at first handle them gracefully, and required substantial duplicate data entry by workers who were still adapting to E-File itself. One unfortunate and unforeseen consequence of the implementation of the E-File system was that pre-existing paper-based claims were neglected as workers preferred to focus their attention on claims in the new system. This damaged overall productivity, and of course was unfair to those whose claims were not fortunate enough to be on the new system. Obviously -- at least in retrospect -- this is an area in which system planners failed to anticipate some of the realities of the process change they were designing. Another area in which implementation of the new system was less than fully successful was staff training. Workers with little or no PC experience were given only a few weeks and a little training to become familiar with the new work platform. In addition to achieving a functional level of computer literacy and learning the new E-File application, many workers had to learn new job functions, and even relocate to a different office, all same time. When the new system was implemented in a particular office, one or two members of the Business Users' Group were posted there to train staff for two to four weeks; but this was not really adequate, and BUG's had to devote their time to ongoing development tasks in addition to this rollout training. Further, frequent system changes and enhancements were announced via emails which staff had neither time nor ability to understand. No additional resources appear to have been allocated for ongoing training to cope with these system updates. As a result, around 85% of WCB employees achieved mastery of “very basic” system functionality, but most staff did not have time to learn or keep abreast of short cuts, enhancements, and other advanced features. Two “technology officers” were appointed to provide ongoing mentoring and trouble-shooting; it is unclear if this was enough to solve the problem. The transition from paper-based processes to a modern, networked, collaborative system obviously constitutes a major culture shift. While most of the consequences of this culture shift were positive, some were not; and while some of these negative consequences were probably inevitable, others could have been avoided, or at least mitigated, by better planning and design. (In all fairness, it would appear from Painter's account that the developers and planners at WCB did rather better than average.) File sharing meant that one worker didn't have to “steal” a file from another; this facilitated working in parallel on different aspects of a case. On the other hand, this also meant that each worker’s entire case load was “screaming” at him/her every day, as opposed to the old system when files left his/her desk while someone else worked with them. Further, a steady stream of additions to each file was visible to all users of each file; this meant that it was easy to be overwhelmed by the flow of information, and to “be managed by the system”. To be effective, users had to be “self-controlled” and not respond to every piece of new information the system threw at them. This represented a system-design flaw: technology should make it easier, rather than harder, to work efficiently. While it is true that users must always make some adaptations to new systems, Painter fails to point out that these "information overload" issues could have been significantly mitigated by better system design. It seems unfair to have required workers to develop "desk management" skills simply to cope with a system that did not adequately prioritize the flow of information. Any computerization project inevitably creates some ergonomic problems. Many people simply do not like reading large amounts of information on-screen; even though they may feel very comfortable working with computers, they prefer to read black print on white paper. There is no technical solution to this, other than providing workers with fast printers, toner, and plenty of paper. It is, after all, a well-known fact that the "paperless office" has in fact been responsible for the death of a great many trees. Other classic ergonomic problems that were seen at WCB include repetitive stress injury, stiff neck and shoulders, and eyestrain -- all common consequences of working extensively with desktop PCs. Some of these problems can be alleviated through better workstation design, "natural" keyboards, and the like; and others can be effectively addressed only by training workers in modern self-preservation techniques. (To avoid some of the stiffness problems, it might be worth designing a system that periodically blanks out the PC's monitor, thus forcing even the most dedicated employee to take a short break and stretch.) Because everything in every claims file is visible to other WCB workers, those entering data into these files are now effectively held to a higher standard of accountability than they were previously. In general, this is probably a positive development; but the increased uniformity and regimentation of work imposed by an organization-wide computer system will inevitably creates some resentment among workers who are used to doing things their own way. While the new system has increased the overall level of collaboration within WCB, it is interesting to note that the amount of face-to-face collaboration and conversation among employees was reduced, as they no longer had to run from desk to desk exchanging paper documents. Further, it became apparent that while the E-File system was a powerful "enabler" of collaborative teamwork, human leadership was still required to maximize the benefit. This is unsurprising -- after all, even the best computer program is still just a computer program. As a whole, it would appear from Bert Painter's account that this was a basically successful exercise in reengineering business processes with the aid of computerization. (Of course, as a painter was personally involved with the project, it is possible that he paints a rosy picture of the process.) Many of the classic mistakes were avoided: notably, workers at all levels had a major input into the development process from its outset, rather than having new systems imposed upon them "from on high". On the other hand, more up-front analysis of WCB's business needs might have avoided a good deal of re-reengineering. Painter does not mention any system of version or release control; and some of the problems he mentions in assimilating a steady stream of system changes might have been avoided by instituting a more coherent system of product releases. On the whole, though, this case study provides a good illustration of how a holistic design and development philosophy and enable major organizational change while inflicting minimal pain. Read More