DuncanLele96 |
PublicReengineering Wiki |
|
Telogy buys, sells, refurbishes, rents and manages test and measurement equipment. Their motivations for change were to be more flexible, allow growth and to achieve a competitive edge - not necessarily cost cutting. They wanted greater functional integration in the business. Their legacy had undocumented source code, They had to hire consultants for modifications. This was "tedious and expensive". They were customising "spaghetti code" and ended up creating more complexity with each iteration. They had 12 full time employees supporting the legacy (an HP mainframe with mostly FORTRAN code) Reengineering began in 1992. No off-the-shelf packages ideally suited their business. They estimated that building a new system from scratch would take 4 years and $24m. They compared packaged solutions and decided on Sybase as their RDBMS over Oracle. Their decision was based on it connectivity and openness which provided a greater selection of third part applications. Additional packages bought were a customer resource package from Aurum software and a manufacturing resource planning package from TXbase. These packages were about a 75% fit for Telogy. Hardware chosen was Sun Unix database and application servers with X-terminals. In addition their are desktop PC clients. They incrementally migrated to the new architecture via 6 functionality oriented phases. The resultant system was reasonably fault tolerant through the use of back-up servers and clients as well as redundant hubs in their network. They outsourced the customisation and integration by outsourcing this function to an Indian company HCL who had USA offices. This avoided having to hire expensive, indigenous contract staff. Gradually systems maintenance was handed over to Telogy staff. The first stage in training was to document existing processes as well as the evolving system. The documented facilitated training and was also used as part of the company's ISO9000 accreditation. On a 3 year basis, Costs of new system were $4.8m - budget was $4.5m. Overruns were attributable to extra customisation, the turnover of users and changing requirements. Total benefits were calculated at $9.45m. The resultant context was: internal and external sales could work together to service customers with no need for hand-offs between them; Order cycle times reduced; Improved responsiveness to customers has increased sales by an estimated 20%; Less paper work; Electronic ordering via web; Sybase triggers exception conditions (eg low stock, overdue deliveries) => quicker responses and shorter cycle time; The introduction of bar code readers increased the accuracy of data; automation of sourcing & purchasing & quote handling by the integration of fax and voice data systems; customers can query orders via the voice data network; former stand-alone PCs are now networked and centrally administered making huge savings and improving communications; better executive reports. During system development, Telogy had to occasionally get vendors together and "knock heads". Departmental representatives were seconded onto the migration task force to help manage the change. They feel rapid module deliveries are important to keep check on user expectations in check. If change is too slow, the users have too much time to think of new requirements. This hinders migration. They feel it is important to anticipate resistance to change, because it will hhappen. Encourage people to cross functional boundaries. They had a data administrator appointed early on to manage data conversion, reconciliation and synchronisation. They felt they should have involved more users than their 2 per department. It would have meant more buy in and quicker training. They rewarded people for buy-in at their annual reviews. Not much mention of code or data migration. Telogy gained competitive advantage by purchasing packages quicker than they could develop in-house. They obtained strategic advantage by tailoring these packages to perform tasks their competitors could not. In addition, they shared risk with their vendors by not having to be solely responsible for updates and maintenance.
Related pages: Bibliography |
| This page last edited on 29 October 1999 |