Hbs_wipro Essay Example

Hbs_wipro Essay Example Hbs_wipro Essay Hbs_wipro Essay He pictured Wipers software products coming off a virtual assembly line with the same quality and efficiency he had witnessed in auto plants employing principles of lean manufacturing. Pop Wiper Technologies had been incredibly successful in selling its software services to companies around the world in all sectors of business. In fact, Technologies provided 76% of the $1. 3 billion in total revenues that its parent, Wiper Limited, earned in 2004. Ball was Vice President of the Manufacturing Solutions vertical within the Enterprise Solutions SUB. His team of software engineers designed systems and applications addressing procurement, vendor development, and production processes for clients around the world in the manufacturing sector. No etc With at least 50 customers in the Manufacturing vertical, Salsas team was continually responding to the individual needs of its clients, and Ball himself was constantly thinking about the most effective way to do this. An engineer by training, Ball had studied the principles of lean manufacturing that had been so well publicized by Toasts automotive plants could be emulated in the knowledgeable business of software development. : A Global Economy Software services was a fast-growing industry in India in 2005, as more and more companies around the world were choosing to buy customized software systems rather than build them themselves. The opening of Indians economy in the sass had allowed companies in the US and Europe, as well as Japan, to discontinue activities in-house that were not cost-effective nor considered part of an organizations core competency, and import them from elsewhere. Hundreds of thousands of qualified software engineers in India and other developing nations were carrying out software bobs at lower cost than in the clients home country. This phenomenon brought a swell of new business to Wiper in the new millennium. The export of software and IT services had brought close to $17 Professor David M. Upton and Research Associate Virginia A. Fuller prepared this case. HOBS cases are developed solely as the basis for class discussion. Certain details have been disguised. Cases are not intended to serve as endorsements, sources of primary data, or illustrations of effective or ineffective management. Copyright 2005 President and Fellows of Harvard College. To order copies or quest permission to reproduce materials, call 1-800-545-7685, write Harvard Business School Publishing, Boston, MA 02163, or go to Hobs. Harvard. Dude. No part of this publication may be reproduced, stored in a retrieval system, used in a spreadsheet, or transmitted in any form or by any means?electronic, mechanical, photocopying, recording, or otherwise?without the permission of Harvard Business School. Copying or posting is an infringement of copyright. [emailprotected] Harvard. Du or 617-783-7860. 606-021 billion in revenues to India in 2004, and had ushered the words outsourcing and offspring into the global business lexicon. Outsourcing To outsource work meant that a company would buy work that was previously done in-house (I. E. Within the company itself). The outsourced work could be done either offshore or elsewhere within the customers home country. Offspring Offspring meant moving work from the companys home country to another country. However, it did no t necessarily involve a third-party. Often, a satellite branch of a company was set up in another country, and the offshore work was done there. Such work was not considered outsourced, because it was still performed under the umbrella of the parent company. Offshore satellites of a single company were called captive centers, or Just captives. Since Wiper Technologies work focused on non- Indian companies based outside of India, its customers were both outsourcing and offspring the work given to Wiper. Wipers Work Back in 2003, NSA Ball and his team in the Manufacturing Vertical took note of the current state of Wipers role in global business. Enterprises had grown rapidly across the globe through mergers and acquisitions, and markets grew more global as barriers disintegrated in many developing countries. At that time, most of Wipers outsourcing work came in two forms: dedicated offshore development centers on its Bangor campus, and in the fulfillment of customers large, enterprise-wide IT projects. Odds Offshore development centers were created for customer-companies who outsourced entire business divisions to Wiper. The DOC was essentially a remote office of the client, though operated by Wiper employees. The initial objective of customers who set up Odds with Wiper was to leverage the lower costs in India. The projects undertaken in Odds varied in size, nature, and technology. Wiper operated about 50 Odds, staffed with anywhere from 50 to 1700 people in each. Large projects Large projects were also outsourced to Wiper for lower cost, but increasingly to leverage the skills of Wipers engineers and other resources that had developed as a result of dealing with similar-scale projects with other customers. One problem facing large multi-national corporations (Mans) was the integration of systems across their various geographic units. Because of their fragmentation, they were not well equipped to handle enterprise-wide system development or changes, so such large rejects, usually for integrating alien systems. Another technological problem for large corporations was procuring and providing middleware between legacy and the new packaged systems they had installed. In general, Wipers large global clients had several business units dispersed around the world, each with projects outsourced haphazardly, some to Wiper, others to local IT services companies, and some to their own internal IT departments. Within that company, the outsourced projects were addressed as follows: each business unit determined the projects it needed to outsource, and selected vendors independently. Solutions were then architect disparately, creating dissonance between units of the company. Usually, only large-scale projects went to a company like Wiper, for it was only those projects that could Justify the overhead cost associated with setting up an offshore engagement, at least from the point of view of the local managers. 1 See statistic: Mascot. Org/newswire/issue [Research. SP 2 The Problem of Small Projects Traditionally, in manufacturing, global companies tended to outsource very large software projects, but keep the many smaller projects those with budgets under $100,000 within their regional IT units. This meant that small projects were handled in one of two ways: kept in-house and completed by regional IT teams, or outsourced locally. When a project was kept in-house, it ran the risk of waiting in a long queue in the internal IT department, because of limited internal capacity and the inevitable backlog. When projects were outsourced to multiple service providers, the customer ended up with a myriad of different technical solutions across the globe. Large corporations with global footprints typically had vendor procurement processes at the local business unit level, and f similar projects did not look the same. More often than not, Wiper saw completely different architectures and completely different platforms created within one company for precisely the same business function. Even though many of these small projects were similar in nature, they were completed in uniform ways because local companies did not feel they could justify sending them to one large vendor such as Wiper. The costs of setting up an outsourcing contract were high, for there were many specifications to be outlined and agreed upon by both parties before the work could begin. The initial steps of evolving such a contract included specifying quality levels, product requirements, and delivery times. (See Exhibit 1). When software solutions were designed ad hoc, and were non-uniform across the company, upgrades and subsequent integration became difficult. This led to a integrated company-wide IT strategy and loss of control of regional IT functions. With such fragmentation, the company was unable to take full advantage of its scale because its systems each required individual maintenance and specialized skills. Having Wiper handle such projects could, Ball believed, lift the client out of the has of diffusion, the chaos of local decision-making, all of which had contributed to a global sub-optimal. If Wiper could streamline the initial steps of engagement, it would be simpler and more cost-effective for customers to hand off small projects, and a whole new stream of business would flow in. Wipers Challenge Although lower cost was the initial reason large companies chose to import services from offshore, Ball was convinced that labor cost arbitrage alone was not enough to keep his business booming, especially since Wiper faced major competitors in its own backyard, among them, Data Consultancy and Inflows Technologies Limited. He wanted Wiper Technologies to be the worlds top source for software services because of the quality of its product, not simply because it was a lowermost alternative. To be competitive in an industry which was itself growing explosively, Wiper had to differentiate itself based on the quality and delivery of its software products, not the price of its labor. New Opportunity Ball wanted to improve Wipers execution of small-sized projects such that the departments. By establishing blanket contracts with large clients, they could take in a stream of small projects but not have to go through the overhead of setting up a new entrant every time. Also, the development process could become much more efficient if Wiper reused some of the components that they developed for other projects, rather than re-creating them with each new project. 3 Rules of Engagement Traditional Model Typically, a Service Level Agreement (SAL) was created based on performance measures and process models agreed upon between Wiper and its client before work on a project began. Performance measures were quantified by work-in-progress and field defects (rejection index), estimated time to complete the project (gauged by not- n-time index), customer satisfaction (rated on scale of 1-5), effort overrun (overage and underage), and production support (response time, resolution time). The SAL also specified the process model to be used. There were various life cycle models that each project could follow, and this depended on the type of project. Development projects, maintenance projects, system conversion projects, and package implementations each had process models specific to the nature of the work. Factory Model Ball realized that companies were reinventing the wheel every time they sent their mall projects to a m ©Lange of disparate local outsourcers, or completed the projects consolidate the initial steps of engagement and offer a more streamlined process for completion of small-scale projects to its large customers, those customers would benefit from greater strategic control. All projects under $KICK, for example, would automatically be diverted to Wiper. This would ensure uniformity across geographic units of a NC and reduce the amount of individual maintenance the company would have to do on its systems. Ball piloted this design under the name Factory Model, in which the parallel recesses of the traditional model were combined into a single stream. Each incoming project was then assigned to a process rather then creating processes around the requirements of individual projects. (See Exhibit 2). Four fundamental processes demand management, centralized engineering and architecture, core factory processes, and infrastructure consolidation served each of the individual projects requiring similar technical or functional solutions. Demand Management This phase consisted of consolidating demand for solutions across geographic regions and business units of large global customers. Wiper employed a central team to manage customer requirements and form a common, transparent demand repository within its Manufacturing vertical. Thus all work of a similar nature and of similar functional areas was funneled into this common demand management function. This led to improved pipeline management, which standardized the bid process, and reduced bid process cycle time by 10-15%. This essentially automated the demand management process. The procurement function changed in that duplication was eliminated across geographies. A web page allowed customers to log requirements for their specific rejects, and this information was stored in the demand repository as well. The entire procurement cycle was cut down by making sure assembling demand and allocating it to functional areas, then moving the requirements to the virtual factory. This was the first area of improved efficiency under the Factory Model. Centralized Architecture and Engineering Services Ball established a core architecture group that identified best processes, improvements, and innovations, and used this information to create templates for possible projects. The use of these templates enforced standards throughout the 4 roof, making it easier to train employees and assign qualified people to any project in the pipeline. This also enabled reuse of components. The centralized architecture and engineering services group endeavored to standardize the finished architecture across various business units and geographies as long as they were in the same functional area. Core Factory Processes This step incorporated specialization of tasks, knowledge reuse, and code-reuse using standards into the design, build, test, and deploy steps that actually brought projects to fruition. Within the Core Factory Processes tag were the PAPAS/PM (Product Process Quality Assurance/ProJect Management Office) features that drew upon elements of the Toyota Production System. Here projects underwent planning and control, metrics analysis, benchmarking, issue resolution, status reporting, and resource forecasting to ensure quality across the different units. Productivity improvements were driven by the use of component libraries, global test beds, and a knowledge management network. Choosing Projects Infrastructure Consolidation This step comprised the standardization of development, testing, and deployment platforms. Common platforms promoted common hardware infrastructure. Software licenses were reused where possible, and infrastructure support teams were optimized. Through a centralized capacity planning model as well as cost allocation mechanisms, this step reduced Wipers operating expenditures by about 15-20%. The Factory Model was best suited for global enterprises that sought to achieve business units. By 2004, Wiper was piloting lean processes in the Factory Model for software development for two large clients. These customers fit the profile of being global, with multiple business units spread across different geographical locations. Furthermore, the projects these customers wanted were small and not interdependent, with a low degree of variability; they were conducive to the Factory Model. Indeed, large global companies were more likely to have repeatable Jobs in their work streams projects that may be small or relatively simple in nature but large in volume. Project requirements coming in from dispersed business units often shared common components, even if they addressed different business issues. Automobile production was analogous in that individual cars on a production line shared a similar design and basic components, but also had features that made each unique. Each of the cars had four wheels, an engine, and a steering wheel, but each also had unique features like sunroof or no sunroof, automatic or standard transmission, heated seats or no heated seats, etcetera. The cars could still move down the assembly line as such, having both common components and unique features. If they were too different, there would be no point in having an assembly line; they would all be custom-made. Ball envisioned a similar scenario with software, and believed that the common components shared by many software products would allow software to be produced a factory-like style. For example, an order management system in Asia was similar to an order management system in the US, in that they both shared common functionality. Like the sunroofs or heated seats, additional features could be added or removed from the basic model according to customer specifications. Once Wiper had built the basic platform, it could very quickly turn around requests for a customized variation on that. 5 Lean Principles ongoing improvement within Wipers software development life cycle as a result of the application of lean manufacturing principles. Lean principles had already improved quality and productivity in many industries, most notably the auto industry with the Toyota Production System. In its own application of lean principles, Wiper outlined the following tenets: 1) Continuous Improvement Go see for yourself to understand thoroughly (genetic sunburst) Make decisions slowly by consensus, thoroughly considering all options, implement rapidly Continuous organizational learning through kamikaze 2) Approach to People: Respect, Challenge, and Grow Grow leaders who live the philosophy Respect, develop, and challenge your people and teams Respect, challenge, and help your suppliers