INFORMATION SYSTEMS MANAGEMENT: Solving Problems through Information Systems Free essay! Download now
Home > University > Business studies > INFORMATION SYSTEMS MANAGEMENT: Solving Problems through Information Systems
INFORMATION SYSTEMS MANAGEMENT: Solving Problems through Information Systems
You can download this essay for free. All you need to do is register and submit at least one of your essays to us.
Or you can purchase this essay for just $2 instantly without registering
Downloads to date:
| Words: 6400 | Submitted: 06-Jun-2010
N/A | Number of pages: | Filetype: Word .doc
DescriptionINFORMATION SYSTEMS MANAGEMENT: Solving Problems through Information Systems
The version included applications pertaining to personal employee data, the HR policy manual, employee salary data and fund balances. Screens and queries were designed to help keep the network traffic low. The second phase of the launch included letting the employees change their name, home address and phone number. To build the software, developers initially considered various vendors offering proprietary APIs available, which enabled the use of PeopleNet's own proprietary interface. However, these APIs locked the software to specific databases and middleware. Xerox then decided to go for Open Database Connectivity (ODBC), because it was supported by almost every client application and database.
Several ODBC drivers were evaluated including InterSolv's DataDirect ODBC Pack, Oracle' ODBC Driver, Microsoft's ODBC Desktop Database Driver and Intersolv's DataDirect SequeLink. Xerox finally selected OpenLink Software's Object Broker as it was reportedly very easy to install and it supported both TCP/IP and Novell's IPX/SPX protocols equally well. Many other ODBC drivers tested (or the middleware on which they ran) worked better with TCP/IP, but not IPX/SPX. Those that supported the latter were quite slow. Most importantly, OpenLink worked out to be much more cost-effective than the other drivers available. The server software, based on Oracle 7 Database, ran under Sun Solaris 2.4 on SPARCServer 1000s, with 512 MB of RAM and 10-GB disk arrays.
Server software also included OpenLink ODBC Request Broker, which communicated with the ODBC driver on the client. The clients and servers communicated over local and wide-area networks, using TCP/IP and Novell IPX/SPX. The client part of the software was under the Microsoft Windows operating system (version 3.1 on a 386 processor or higher, with 8 MB RAM and 15 MB of available space on the hard drive), written in Visual Basic 3.0 with a local Microsoft Access database (Refer Figure I).
The project followed a phased development approach of prototyping, testing, re-testing and then rolling out on a continual basis. Visual Basic was selected as the client development tool because of its ability to facilitate prototyping. The Microsoft Access engine acted as the invisible middleware component, which tracked configuration and routing information and stored cached data.
The ODBC Driver worked with a related component on the server to transmit and route requests and data between the client and server. The ODBC driver also provided other functionalities, including transmission-level encryption for data traveling over the network and a query and transport vehicle for automatically updating client systems.
Xerox PeopleNet supported applications covering such areas as training, retirement fund performance and a corporate phone directory (Refer Table I).
In addition, employees could check Xerox's stock price as well as those of its competitors.
The unique feature of Xerox PeopleNet was that unlike typical HRMSs, it did not restrict the availability of information HR staff alone.
All employees could access information through any PC on the company's network.
Xerox PeopleNet MODULES
• Employee recognition programs
• Phone Directory
• Company-wide electronic bulletin
• Stock quotes
• Calendar-based reminder system for key HR activities
• Work group organization charts
• Total cash compensation
• Employee demographics • Personal and salary information
• Training transcripts
• Training catalog
• Profit-sharing fund balances
• Retirement planner
• Benefits guide
• The human resources policy manual
Source: Microsoft User Story "Xerox PeopleNet," www.webfrontier.tridec.com.
Xerox PeopleNet cost Xerox around $2 million. However, its benefits far outweighed the investment. The solution helped Xerox accomplish its objectives of empowering its people, increasing satisfaction and boosting productivity. In addition, online publication of the human resources manual and other publications saved approximately $1.5 million annually in printing costs.
Online transaction processing and electronic signature approval capabilities added later saved another $1.1 million annually by eliminating manual forms and paper-based processing.
On the hiring front, managers could open the Xerox PeopleNet application on the desktop, create a posting on an online form and post it immediately on a central electronic bulletin board. Any interested Xerox employee could then print an application form and submit it to the hiring manager in paper form. The paper element was to be completely eliminated over a period of time and internal job applications were to be processed entirely online.
The system included a feedback feature that let employees suggest new ideas and improvements. As a result, employees were able to monitor their profit sharing and retirement plans and change their contributions from their desktops itself.
Interestingly, Xerox PeopleNet seemed to have had certain undesirable results as well. Commenting on the massive layoffs by Xerox during the 1990s, analysts said that so long as software such as Xerox PeopleNet continued to render personnel redundant, the trend of manpower trimming was likely to continue.
However, Mihara seemed to be rather pleased with Xerox PeopleNet, "We now have a vehicle for accomplishing our objective of empowering managers and employees.”
Mercedes Benz : The Factory Delivery Reservation System
"One of our most fundamental goals in developing the system was to strengthen and market the Mercedes-Benz brand in the United States. The fact that we would be one of the first car manufacturers in the United States to have a factory delivery program would be seen as a very positive thing in this regard."
- William Engelke, Assistant Manager, IT Systems, Mercedes Benz US International, commenting on the FDRS.
By 2000, Mercedes Benz United States International (MBUSI), builder of the high-quality M-Class sports utility vehicle (SUV), established itself as a company that also delivered superior customer services. One such service was the delivery option where by the customer could take delivery of the vehicle at the factory in Alabama, US.
The program called the Factory Delivery Reservation System (FDRS), enabled MBUSI to create and validate 1800 orders per hour. FDRS also automatically generated material requirements and Bills of Material for 35,000 vehicles per hour. The Customer Relationship Management (CRM) solution that made FDRS possible was based on Lotus Domino and IBM Netfinity server.
Analysts felt that with its innovative use of the new program, MBUSI not only managed to improve its customer relations by providing the best service, but also demonstrated its commitment to customers by making them an integral part of the process. Customers were, in a way linked directly to the factory floor – which was a powerful sales tool.
Background: Mbusi and its Business Challenges
MBUSI was a wholly-owned subsidiary of DaimlerChrylser AG.5 In 1993, Daimler Benz realized that the 'Benz' brand could be extended to wider market segments. Traditionally, Mercedes Benz6 appealed to older and sophisticated customers only. Daimler Benz wanted to attract customers below 40 years of age, who wanted a rugged vehicle with all the safety and luxury features of a Mercedes.
Daimler Benz decided to develop a SUV known as the M-Class. It expected strong demand for the new vehicle and therefore planned to build its first car-manufacturing facility – MBUSI – in the (Tuscaloosa, Alabama) US. The MBUSI facility had many advantages. First, labor costs in the US were almost half that of in Germany. Second, the US was the leading geographic market for SUVs.
Third, as the vehicles were assembled in the US, they could be distributed to Canada and Mexico more efficiently. In January 1997, the factory started production at partial capacity and by the end of the year, it was producing at full capacity.
By 2000, the factory was rolling out around 380 vehicles per day. The new M-Class ‘all-activity'vehicle represented a new concept for the company.
Also, mass customization required that each vehicle be treated as a separate project, with its own Bill of Material. To deal with these challenges, Daimler Benz decided to implement an enterprise wide Information Technology (IT) system, with the help of IBM Global Services.
To further strengthen the image of Mercedes Benz in the US, MBUSI planned to deliver vehicles at the factory, becoming the first international automobile manufacturer in the US to do so. MBUSI also wanted to enrich the customers'experience. Commented William Engelke, “The factory delivery option gives Mercedes-Benz customers something that they do not get from other automobile manufacturers which is why we think the program will resonate with our customers. We think that having the factory delivery program available to Mercedes customers adds to the overall experience of the customer.”
The Design of FDRS
The FDRS program was proposed in the first quarter of 1998. In the third quarter of 1998, MBUSI entered into a contract with IBM. A development team was constituted with IBM Global Solutions specialists and IBM e-commerce developers, who worked closely with MBUSI. The program became operational by the first quarter of 1999. The IT team at MBUSI had a clear set of functional specifications for FDRS. However, they relied on IBM to transform the concept into an e-business solution. The FDRS was designed in such a way that customers buying the M-Class SUV could specify that will take delivery of their new vehicle at the factory.
They could place the order at any of the 355 Mercedes Benz dealers in the US. An authorized employee at the dealership entered the factory delivery order the web interface.
Timing was the most important aspect of the FDRS'functionality, as it was closely linked with MBUSI's vehicle production schedule. Mercedes Benz United States of America (MBUSA), based in Montvale, NJ, was the first link in the FDRS program.
It was the point where the dealer actually placed the order. MBUSA's role was to coordinate the distribution of vehicles to dealers across the country. Later, it had to add the order to the company's Baan Enterprise Resource Planning (ERP) system, which scheduled the order for production.
About three months before the production date, the dealer could schedule in a window, the date and time of arrival of the customer at the factory for delivery. The window was then automatically computed by the FDRS to give the dealer, the possible delivery dates.
Apart from the delivery date, the customer could also specify the accessories for the car and also request a factory tour. FDRS was based on Lotus Domino (Refer Exhibit I), Lotus Enterprise Integrator and IBM Netfinity servers. It also interfaced with IBM S/390 Parallel Enterprise Server, Model 9672-R45 located in Montvale, NJ (Refer Figure I). There were two Domino servers – an IBM Netfinity 5500 and an IBM Netfinity 3000.
SYSTEM ARCHITECTURE OF FDRS
The former that acted as the ‘internal Domino server'was placed behind a firewall. It replicated databases through the firewall to the external server. The replication, which was encrypted, represented the primary means by which the FDRS system achieved security.
Netfinity 3000 acted as an ‘external Domino server.'It had public information and was also the primary communication linkage for dealers. The back-end of the FDRS was equipped with an Oracle database that updated the internal Domino server database with order information.
The updation was done using Lotus Enterprise Integrator. The data which was replicated to the internal Domino server included lists of valid dealers and lists of order numbers.
When an order was placed by the dealer on the FDRS system, the data was first stored on the external Domino server, after which it was replicated to the internal Domino server. Then it was replicated to the back-end database via the Lotus Enterprise Integrator. Data replication between the Lotus Notes servers happened every 15 minutes and data exchange with the back-end database three times per day.
There was also a link between the back end database and an IBM S/390 mainframe based system located at MBUSA via a T1 line. MBUSA managed the flow of vehicles to Mercedes dealers across the United States.
This mainframe based system, received new vehicle orders (as opposed to factory delivery reservation requests) from individual dealers. The orders were then sent to MBUSI's Baan system and also to the back-end database.
The vehicle ordering and factory reservation data were coordinated with each other when the back-end database uploaded the data to the internal Domino server. This coordinated the production and delivery information.
One of the most challenging aspects of the implementation seemed to be the complexity of the Lotus and Domino scripts. The development team had to group all the information from diverse systems. Commented William Engelke, “There was a substantial amount of very complex coding involved in the FDRS solution. This application involves a lot more than having our dealers fill out a form and submitting it. There are many things the servers have to do for the system to function properly, such as looking at calendars and production schedules. We built a solution with some very advanced communication linkages.”
IBM faced many technical challenges during the implementation of the program. One of them was the different timing schemes of the Lotus Notes databases and backend databases (ERP). This led to discrepancies in the data. Domino server was a Near Real Time (NRT) Server, and MBUSI's backend activities were both real time and batch processing. Also, to get the best results, the Domino server was an optimised subset of the ERP table set. However, the development team achieved a balance between the two ‘sides'of the solution by focusing on issues of timing, error detection schemes, and alerts.
Customer Satisfaction: FDRS'Primary Benefit
MBUSI seemed to measure FDRS'success in terms of increased satisfaction of its customers. The company also believed that the marketing and customer satisfaction aspects outweighed the significance of more traditional cost-based benefits. Apart from the factory delivery experience, the program also offered the customer a factory tour and ride on the off-road course at a low cost.
The company also seemed to gain strategic marketing benefits from the FDRS program, as it was able to establish Mercedes-Benz as a premium brand. (Refer Table I for advantages of FDRS in different areas). Customers could also visit the various tourist spots in Alabama after picking up their M-class vehicles. The NRT Server System supports real time distribution of near-real time data.
ADVANTAGES OF THE FDRS PROGRAM
Strategic Marketing Benefits FDRS was expected to improve customer satisfaction and brand loyalty, as it enriched Mercedes' customer's experience. The program also strengthened the brand image of Mercedes in the US.
Cost Savings Development of a web-based solution enabled MBUSI to offer the factory delivery program at substantially lower costs, due to less reliance on administrative personnel.
Regional Economic Development “Package Marketing” the FDRS program with a ride to tourist sites, enhanced the image of Alabama as a tourist destination.
DaimlerChrysler AG The creation of a similar – albeit smaller – factory delivery system to the European Customer Delivery Center in Sindelfingen, Germany, reflected favorably on the MBUSI business unit.
Future of FDRS
In 2000, MBUSI planned to leverage FDRS'platform by adding a range of other services. MBUSI built an advanced platform to create communication links to its suppliers. Through the link, MBUSI provided them feedback on the quality of supplies it received. The dealers and suppliers had a user-ID and password, which the system recognized.
It then routed them into the appropriate stage of the FDRS. The company also planned to extend the innovative system to include transactional applications such as ordering materials and checking order status on the Web. The company expected that the new system based on FDRS, would be more cost-effective than the Electronic Data Interchange (EDI)18 system.
Supply Chain Management
(SCM) System at Cisco
"Networked manufacturing processes have enabled Cisco to manufacture new world products with new world processes, resulting in a competitive advantage for Cisco and enhanced satisfaction for Cisco customers."
- Carl Redfield, Senior Vice President, Manufacturing and Worldwide Logistics, Cisco Systems, in 2000.
A Company in Trouble
In August 2001, the San Jose, California based, computer-networking company Cisco Systems Inc (Cisco) surprised industry observers by announcing its first ever negative earnings in more than a decade. In the third quarter of fiscal 2001, the company's sales had decreased by 30%. Cisco had to write off inventory worth $ 2.2 billion and lay off 8,500 people. By the end of 2001, the market capitalization of the company was down to $ 154 billion and per employee profit was $ 240,000 (down from $ 700,000 in 2000).
This was in sharp contrast to the situation in early 2000, when Cisco was one of the most successful companies in the Internet world with a market capitalization of $ 579 billion (It had become the world's most valuable company surpassing even Microsoft's market capitalization of $ 578 billion).
According to John Chambers (Chambers), Cisco's CEO, neither the company's software nor its management were to blame for the company's poor performance. Analysts were puzzled that while other networking companies, with far less sophisticated information technology infrastructure than Cisco, had begun downgrading their forecasts in the wake of the impending downturn in the industry months earlier, Cisco did not lower its inventory like other companies. What came however as the biggest surprise were the allegations by some analysts that the company's 'highly regarded' systems were to be blamed for this situation. According to analysts, over reliance on technology prevented Cisco from seeing the impending downturn that was clear to everyone else and led the company down a disastrous path.
Cisco – The Networked Supply Chain
Cisco was founded in 1984 by a group of computer scientists at Stanford. They designed an operating software called IOS (Internet Operating System) that could route streams of data from one computer to another.
The software was loaded into a box containing microprocessors specially designed for routing. This was the router, a machine that made Cisco a hugely successful venture over the next two decades (Refer Table I for details of Cisco's growth).
In 1985, the company started a customer support site through which customers could download software over FTP and also upgrade the downloaded software. It also provided technical support through e-mail to its customers. In 1990, Cisco installed a bug report database on its site. The database contained information about potential software problems to help customers and developers.
Download this essay in full now!
Just upload at one of your essays to our database and instantly download your selection! Registration takes seconds
Comments and reviews
Reviews are written by members who have downloaded the essay
No comments yet. If you download the essay you can review it afterwards.