General Notes"What do you mean we have to change the way we make our candy bars? They are the number one selling product we have. Everyone loves them. Why can't we just keep doing things the way we've always done them? It's worked fine this long." It's not unusual to hear this type of dialog in companies, large and small, all across the world. Change is hard on people and organizations. But it's one of those necessary evils that keeps companies in the lead or helps destroy them. In this chapter, we're going to focus on using information systems as a way to successfully help redesign organizations so they can improve their current processes or establish new ones. 14.1 Systems as Planned Organizational ChangeIt would be nice if we could give you a precise checklist of how to establish an e-commerce organizational design plan, but we can't. No one can. What we provide in this chapter is information you can use to help plan and analyze organizational changes not only for e-commerce, but also for other improvements. The triangle that we've used before is back…
All three elements will pose their own unique challenges to managers, but you may be surprised to learn that the hardware and software will probably be the easiest of the three to manage. Successfully reorganizing the company relies on more than just bringing in new equipment and new programs. Understanding and incorporating the social and political climate in any plan is one of the most important aspects.
Linking Information Systems to the Business PlanToo many companies buy the hardware they think is necessary for a new or improved information system. Then they purchase some software to go along with the new hardware. Now they realize their hardware is inadequate for the new software, so they buy more powerful hardware. And the vicious circle continues. Pretty soon they have a whole bunch of hardware and a lot of expensive software, but do they have an information system? Only if they have made sure all the hardware and software purchases fit in with their organizational information systems plan and their people know how to use them. "A what?" you say. "Another plan that stifles creativity and creates roadblocks to getting work done?" No, a good information plan will help companies systematically figure out what they need to get the job done and whether all the hardware and software is necessary and if they really do meet the requirements of the organization. A good information plan will also take personnel needs into account and help determine how all three elements of the triangle will work together for success. The problem is that too many companies don't have a plan for integrating new hardware and software purchases into their overall business plan, let alone meshing them with the persware side of the triangle. Of course, the information plan should support the overall business plan and not conflict with it. The plan must include all levels of the organization, including the strategic and executive levels. These two levels contain the people who often say they are exempt from having to determine information system needs. And don't forget the persware – the "people" requirements, the most important part of the whole thing.
Establishing Organizational Information RequirementsEver heard the old saying, "If you don't know where you're going, how will you know when you get there?" Well, in order for a company to be successful, management needs to have a good idea of where it's going and how it's going to get there. Management also needs to know what tools it needs along the way.
Enterprise Analysis (Business Systems Planning) Enterprise analysis, or business systems planning, uses the "big picture" approach. That is, you look at the overall organization and figure out how each unit, each function, all the processes, and each data element fits in. Think of a jigsaw puzzle: each piece is a vital part of the whole. To understand the informational needs of an organization, you first need to understand the organization. To do enterprise analysis, you first ask each manager or a large sample of managers the following:
You then compile that input into logical application groups. Now you can get an idea of how the processes work, who uses them, and how they fit together. Do you realize how long this process can take? Do you know how expensive it can be to get the managers to complete the input? Remember that the information will probably be biased because managers will operate from their own personal agenda – it's human nature. And what about the informational needs of non-managers? Don't they count? The biggest drawback to enterprise analysis is that it only asks questions about current processes and current uses of information. Nowadays this isn't good enough, especially when it comes to e-commerce and integrating new technologies. Enterprise analysis doesn't focus on the need for new processes or new methods of conducting business.
Strategic Analysis or Critical Success Factors Critical Success Factors (CSFs) are simply the goals managers feel will make the organization a success. Using this method does broaden the scope of the analysis to include entire industries, the broader environment in addition to the firm itself and its managers. That's why it's called "strategic analysis." Basically, you contact several top managers, ask them what they think will make the organization succeed, and then combine the results into a cohesive picture.
Table 14-2 gives some good examples of critical success factors and how they mesh with organizational goals. What makes this method work is that you have a much smaller sampling of data with which to develop an information plan. It's faster than enterprise analysis and therefore a little cheaper. And your plan revolves around just a few CSFs instead of a whole slew of information requirements. Using the CSF method also takes into account how the external business environment affects information needs, which is a tough question nowadays. Usually top management, the organizational level most involved in this type of analysis, has a better idea of the environmental effects than lower levels of management. But hold on a minute. With all its advantages, there are some distinct disadvantages to this approach. Chief among them is that only a small group is interviewed. Their biases then become the biases of the system. How do you formulate the opinions of these few managers into an organization-wide plan? How aware of common tasks at the lower levels of the organization are the top managers? Are you sure managers' goals represent the organization's goals? You hope so, but you don't know. Just because this level of management may be more aware of the external environment doesn't make the plan immune to change. That has never been truer than in today's rapidly changing world. CSFs can be a good start to analyzing a company's organizational needs, but they shouldn't be the only methodology used.
Systems Development and Organizational ChangeChange is disruptive. Change is dangerous. Change is good. Change is necessary. Change is constant.
The Spectrum of Organizational Change
This figure shows the four degrees of organizational change. Automation is the easiest (except for those people losing their jobs), and the most common form of change. But that doesn't mean you don't have to plan for the change first. Rationalization of procedures causes the organization to examine its standard operating procedures, eliminate those no longer needed, and make the organization more efficient. It's a good thing, as Martha Stewart would say! Both types of change cause some disruption, but it's usually manageable and relatively accepted by the people. Business process reengineering, on the other hand, can cause radical disruption. The mere mention of the term nowadays strikes fear in the hearts of workers and managers at all levels. Why? Because many companies use it as a guise for downsizing the organization and laying off workers. Business process reengineering causes planners to completely rethink the flow of work, how the work will be accomplished, and how costs can be reduced by eliminating unnecessary work and workers. But if you want to talk radical change, take a look at paradigm shifts. Now we're talking about changing the very nature of the business and the structure of the organization itself. We're talking whole new products or services that didn't even exist before. We're talking major disruption and extreme change! The best example of a paradigm shift is looking right at you. Higher education is undergoing a major paradigm shift in the online delivery of education. Classes are now offered through the Internet so that students don't even go to classrooms. Many tried-and-true teaching methodologies are being radically altered to accommodate this shift in how education is offered. The Internet is causing all kinds of industries and businesses to alter their products, their services, and their processes in radical ways. Entire organizations are being created to handle the paradigm shifts involved in e-commerce. Look at the automobile industry as an example of this type of change: Traditional dealerships are being disrupted by automalls and online buying opportunities. How can a local dealer compete on price with these two environmental challenges? What is the dealers' role in the revolutionary changes taking place all around them? If business process reengineering and paradigm shifting are so disruptive and so dangerous, why even try to do them? Because companies realize they have to take on the challenges in order to stay competitive. They have had to cut costs and streamline their operations because of global economic pressures, in addition to meeting the demands of their shareholders. And done well, the rewards can be tremendous.
14.2 Business Process Reengineering and Process ImprovementBecause BPR and TQM are such hot topics in the corporate world, let's look at them more closely.
Business Process ReengineeringIn order to make BPR successful, you must first redesign the process, then apply computing power to the new processes. If problems existed in the process before the new system was installed and those problems aren't resolved, the new system could actually make them worse. Very few processes in business are as efficient as they can possibly be. It's a fact of life. The idea behind successful BPR is to find improvements or even new opportunities. For instance, Federal Express and UPS both have online package tracking systems. That simple process was never economically feasible before the Internet. They had to reengineer their business processes to incorporate this new paradigm shift. New information system software is giving businesses the methodology to redesign their processes. Work flow management offers the opportunity to streamline procedures for companies whose primary business is oriented toward paperwork. Instead of 10 people handling a single bank loan application, you can install software that will speed up the process, allow several people to work on the document at the same time, and decrease the total number of people who handle it. Or, you can migrate the application process to the Web and make it even more efficient and customer-friendly. Wells Fargo Bank allows customers to complete an online mortgage application and receive a preliminary approval or disapproval within minutes. Wells Fargo's computer system is connected to the credit reporting agencies' computers for quick access of customer credit data. If customers have questions about the application or the types of loans available, they can initiate an instant messaging session with a bank employee and get all their questions answered on the spot. Once the application has been submitted, the customer can check the progress of it online. Once the loan is approved, the money is allocated to the customer through an online account. Wells Fargo processes more bank loans faster and more efficiently. The customer is happier with less effort. And all of this can take place 24/7.
Steps in Effective ReengineeringBPR attempts fail 70 percent of the time. That's an astonishing figure when you think about it. What if your car failed to start 70 percent of the time? Some of the reasons for the high failure rate are lack of planning, management's inability to fully comprehend the enormity and complexity of the effort, and the fact that BPR usually takes much longer than expected. What can organizations, their managers, and workers do to help make BPR a success? It may be helpful to make a diagram of how your processes work now and then envision how they will work after they are redesigned. Figure 14-4 in the text shows an example of how mortgage processing was redesigned using BPR techniques. Try just a few processes to get your feet wet and then expand it to other units or processes within the organization. Document how much your current processes cost. You'll be able to measure costs savings (or costs increases) better if you have a baseline for comparison.
Process Improvement: Business Process Management, Total Quality Management (TQM) and Six SigmaWho wants to eat a candy bar that tastes horrible, drips all over your hands and clothes, and costs way more than it should? WorldWide Candy Corporation from Chapter 2 avoids those pitfalls better than the competition because it has decided to use its information systems to enhance the quality of the company and the product. The customer knows that Cybernuts is far superior to any other candy bar in taste, and it's not that expensive. The customer doesn't really focus on the fact that chocolate isn't melting all over her hands. That's an intriguing aspect of keeping the customer happy, when you think about it. The customer doesn't consider the quality of a product until it isn't there. Then it may be too late for the producer to win back the customer.
Business Process Management Take a seemingly simple task such as sending out customer invoices and really analyze how many steps are involved in the process. Even in a small business, you may be surprised how many steps there are. Business process management (BPM) is the art and science of analyzing every task in a business and helping firms continually optimize them. BPM includes work flow management, business process modeling, quality management, change management, and standardizing processes throughout the organization. Every business, from the smallest to the largest should continually analyze how they accomplish every task and look for ways to improve everything. The business doesn't have to accomplish this with the idea that every process should be automated even though many can. The business simply has to continually look for better methods of performing the work.
Total Quality Management and Six Sigma Total quality management, making quality control everyone's responsibility, relies on an excellent information system to supply workers and management with the data necessary to improve products and drive down costs. Six Sigma is another initiative companies use to spot problems and correct them before they are too deeply embedded in the company's processes. It just stands to reason that the longer a flaw is allowed to fester in the system, the more problems it may cause. And the more problems, the higher the costs. So if you can identify the defects early on and eliminate them, you can achieve more efficient production at lower costs. That's the premise behind Six Sigma. The lack of good, useful information may not be apparent until the organization can't figure out what it's doing wrong, or doing right. Data from all the types of information systems we discussed can be fed into quality management and make it easier to develop and improve products that blow away the competition.
How Information Systems Support Quality Improvements Here are some ways companies can use information systems to achieve total quality management:
14.3 Overview of Systems DevelopmentSystems development includes every resource and every step that goes into producing an information system that solves a problem or helps the organization take advantage of new opportunities.
Don't start by thinking, "Oh, we're going to develop a new computer system? Well, that problem belongs to the IT (Information Technology) department." Nowadays, system development belongs to you as much as it belongs to the techies. You have to work hand-in-hand from start to finish with the entire organization to develop a usable system that will serve everyone. The arrow in Figure 14-5 goes in only one direction. Remember that just because you apparently completed one step doesn't mean you can never go back to it at some point in the development process. In fact, many of the steps should be revisited several times, especially if you are using the prototype method of development.
Systems AnalysisSo what's the problem? Answering that question is harder than you might think. You have to analyze the current situation to determine the real cause of the problem. Make sure you're addressing the real problem and not just the symptoms. Effective systems analysis, adequately determining the real problem, is the key. Write down everything you do in this stage, especially when it comes to what the real problem or opportunity is. Constantly review it throughout the rest of the system development process to remind you and others of what you're trying to do and where you're trying to go. It's natural to stray from the path! Most of all, determine how your objective fits in with the rest of the current information systems and the business plan itself. Is your idea even feasible? You might be surprised how often organizations fail to ask this question. A feasibility study helps you determine if your proposed solution is achievable before you spend thousands of dollars. The study will review the technical feasibility of hardware, software, and persware when you're deciding whether your proposed answer is the right one. Too often organizations underestimate the cost of a new system, especially in the persware area: training, downtime, lost productivity, and employee disruption. The feasibility study will help determine the economic feasibility of the idea. Something's got to give with the new system. What are the changes, who will manage them, and how will they be incorporated into the existing organizational structure? How much change can the organization handle, monetarily and emotionally? Those are the questions the operational feasibility study will help you answer.
Establishing Information Requirements Figuring out who needs what information, where, when, and how will challenge the political dynamics of any organization. No system can answer every need, so you're going to have to decide who gets what. That's why you must write down the problem and then keep referring to your notes throughout the development process. It is too easy to get sidetracked by politics. You must think and then rethink the proposed solution. Make sure you thoroughly investigate the information requirements – you're going to live or die by the outcome. Whatever happens at this stage will carry through to all the other stages. The final dilemma is whether a new information system is really the answer. Would it be better to address the problem through management changes, more training, or changing existing organizational processes?
Systems DesignCongratulations! If you get to the systems design stage, it means you managed to live through the analysis phase. Now you can get down to figuring out how the system will actually solve the problem or help you take advantage of new opportunities. Remember, your goal is to fit the system into the organization and not make the organization fit the new system. Or at least you want to keep them in tandem; that is, the organization should decide what technology is necessary, while the system capabilities can help reshape the organization. When we discussed database management systems, we distinguished between two methods of viewing data: the physical design (how the data would actually be stored in the system) and the logical design (how the data would look to the user). Use the same definitions when you are designing your system, and concentrate on the logical design. In addition to elements that the authors point out in the text, the physical design should determine how the new system will support the current organizational structure, or spell out the changes in that structure that will successfully integrate the new system.
The Role of End Users Unfortunately, the physical design sometimes overrides the logical design. Why? Because the non-techies give up too much control to the techies. This is a reminder that both sides have to work together, keeping the goals of the system as the number one priority and remembering that the best system is one that meets the user's needs. Don't forget that people are the most important component of any system. As soon as users begin to feel they have little input into the development process, you are courting disaster. Keeping the end user involved will produce a better system.
Completing the Systems Development ProcessNow that you're through the analysis and design phases, you can move on to the remaining steps in the process. Just remember, you can always go back to those two steps and probably should at some point.
Programming The actual programming phase will in all likelihood be carried out by the IT department. If you're using a fourth-generation language, the programming could very well be done by the end user. Either way, make sure that the programming supports the analysis and design phases. If not, go back and work through them again. It could very well be that what was designed simply can't be programmed. The usual impulse is to program around the design flaws. Don't! Redesign instead.
Testing "Hey, it works!" But does it really work as it was designed in a real-world situation? Was every aspect thoroughly tested by independent testers in the actual setting? Several things that go wrong in this phase of the development process can severely hamper the project's success. For one thing, this step is glossed over by both techies and non-techies. People assume that because something was designed and programmed according to the specifications in the analysis stage, it is right. So they just fly right through the testing process. Or they run one or two tests, usually by the very people who designed and programmed the system. "Hey, I know it works 'cause I programmed it." Uh,oh! Wrong! You should never have the people who were involved with the design and programming stages do all the testing. Get a fresh pair of eyes to look at the system according to the test plan that was developed by the programmers and the users. Most of all, if you do find a flaw in the testing, do not give into the temptation to ignore it or explain it away. Go back to the analysis, design, and programming stages. Get rid of the flaw the right way. Of the three types of testing explained in the book, unit, system, and acceptance, the last is the one that is most important and yet the most underrated. Managers and users must be adamant about testing the system, measuring it against the analysis and design requirements, and then accepting the system only when it does in fact measure up.
Conversion You're getting close to the end. You've been through the agony of analyzing, designing, programming, and testing. The system meets the requirements, works right, the end users love it, and now the bosses are clamoring to see some results. There is no right way or wrong way to implement the system; you have to look at it in the context of your particular organization.
However you convert, make sure everyone knows what's going on. Tell them through documentation of a formal conversion plan and not the grapevine. Use the information you gathered in the earlier stages of the development process to help guide the implementation plan. Make sure you figure out how to convert the data and train the users. User resistance through fear of the unknown can destroy all your hard work and planning.
Production and Maintenance You buy a new car and think your problems with the old junker are over. Only for a while: Eventually, you're going to have to change the oil, buy new tires, get a new air filter. Sooner or later, the new car will become an old car. The same is true with an information system. After you install the new system and it's in production, you want to go back one more time and make sure it's meeting your needs through a postimplementation audit. Eventually you're going to have to perform maintenance on the system no matter how well you designed and built it. And someday you'll have to make major changes or replace it altogether.
Modeling and Designing Systems: Structured and Object-Oriented MethodologiesThere's always more than one way to accomplish a task. The trick is to use the one that works best for the job you're trying to accomplish.
Structured Methodologies Traditionally, systems have been structured in a very orderly manner. The methods used to build the systems began at the top and progressed to the lowest detail always with an eye towards keeping the processes separated from the data. The designers sketch out how the data moves through the system by using data flow diagrams. The designers could easily track all the processes and their interrelationships by using the data flow diagrams. The DFDs can be used to help spot trouble areas before the system is actually built. Figure 14-7 shows a typical data flow diagram.
The advantage of using data flow diagrams is that they can be used to show a very general, high-level process or very minute detail using the same tools. Anyone can view the overall system and then easily drill down through the diagrams to lower levels of the system. Couple the DFDs with a data dictionary and you can develop process specifications that describe how the data is transformed into useable information. Hierarchical structure charts complete the structured methodology by providing top-down charts that show each level and how they interrelate.
Object-Oriented DevelopmentMost software development methods keep data and processes separate. Object-oriented software development combines the two and treats them as one object. More importantly, the objects are created once and, if they are done right, can be used many times over. That reduces the cost of creating new objects once you have built up a library of objects. It also makes it easier to create new software, because you aren't continually starting from scratch. One tool businesses can use to create new software is object-oriented programming. This programming language has become much simpler for nontechnical people to use. This type of programming treats text, tables, pictures, or groups of data, as an object that can be manipulated and programmed to do special functions. It requires some in-depth training and time to learn, but this kind of programming is very functional for small businesses or a particular department. It can save time and money by allowing the end user to develop a whole program without the help of computer professionals. The terms used in this section, classes and inheritance, describe how object-oriented programming uses objects to develop a program. It may sound complicated, but it really isn't. Figure 14-9 shows you how classes inherit the common features of their superclass. Take a few minutes to study it.
Two important tools used in object-oriented programming are structural diagrams and behavioral diagrams. These tools are part of the unified modeling language (UML) which has become the industry standard for use in this type of programming. The structural diagrams help you understand class relationship while behavioral diagrams help you understand what the system does versus how it accomplishes the process. Both diagrams are equally important in understanding class and inheritance characteristics of object-oriented programming.
Computer-Aided Software Engineering If we've automated just about everything else with software, it shouldn't be a surprise that we're also automating software design and development. Computer aided software engineering (CASE) provides developers with an easy to use method of developing software code that is well-documented, well-designed, and easily reused. Because software programs are becoming so complex it's not unusual to have teams of programmers develop the code. CASE tools provide an element of coordination and management for the programming teams. CASE tools also help keep programming elements such as data flow diagrams and data dictionaries synchronized. CASE tools bring discipline and structure to the program design and development process that may otherwise be lacking.
14.4 Alternative System-Building ApproachesIf you've ever watched a house being built, you know everything starts with the blueprints. One page of the blueprint set has an overall picture of how the house will look when it's done. Another page gives a front view, a side view, and a back view. There are several pages with extremely detailed drawings showing where and how everything fits together. You wouldn't dream of building a house without all of this documentation – at least we hope not.
Traditional Systems LifecycleThe systems lifecycle describes large- and medium-size systems projects. It has existed for years and uses tried-and-true methods that help ensure the success of the system from its humble beginnings as an idea to an old relic that eventually needs replacing. The traditional lifecycle may seem rigid today: There are very definite roles for techies and non-techies. In fact, the user is left out of the loop on a lot of the development and implementation. Even though end users or managers have to sign off and accept the system at the end of each stage, they are not as involved in this method as some of the others we'll look at later. Don't think your job is done once the system is installed and fully operational. You still have work to do: You need to review the original specifications against the finished product and make sure they are met. Are users adequately trained, or do you still need work in this area? Does the system need a little bit of tweaking to make it run better? Is it fully integrated and supportive of the rest of the organization and the overall business plan? Double-check just to make sure. Users shouldn't feel they have to accept errors or products that don't meet their specifications. Your job at this point is to uncover those areas that do need changing before they become a way of life. Do it early, when it's still easy to make changes. Finally, the system will break down or become obsolete and you'll have to start all over – just like the house that seemed so perfect 10 years ago and now seems small and outdated. It's the nature of the beast. The lifecycle approach works well for major systems but doesn't fit the bill for smaller ones. It's expensive, time-consuming, and sometimes doesn't allow techies and non-techies to work together as they should.
PrototypingFast, cheap, user-centered. Prototyping can be the best way to develop a new system if the end users don't have a clue about what they really want the end product to look like. Even if they have a few clues, this approach works well because the user can guide the process based on what they see as the system is built. Have you ever watched a television show where the police artist draws a picture of the crook as the victim looks on? The artist draws the eyes and gets approval from the onlooker. Then the mouth is sketched in and approved. Pretty soon a composite drawing is completed, and the cops are off and running. That pretty much describes the iterative process used in building a prototype system. You would generally use prototyping for very small systems or small parts of a larger system. You wouldn't want to use this method to build a company-wide information system. It can be too unstructured, making it harder to manage in large projects. Prototyping works well when you're developing user interfaces and output reports – areas the users will see the most.
Steps in Prototyping The text outlines the four steps you use when developing a prototype. The important thing to keep in mind is that these steps should be repeated many times over. If you work through them just once, you might be in trouble. Some additional tips: Step 1: Ask lots of questions. If you are the developer, make sure the user signs off on every step of the process. Verify that the prototype does in fact meet the user's needs. If you're the user, are you happy with the new system and does it work well for you? If not, why not? If not, go back to Step 3.
Advantages and Disadvantages of Prototyping Prototyping can be less costly than the traditional systems approach, but if you fail to follow some of the basic principles of systems development, it can be more costly. For instance, if you ignore the basic principle of how the prototype fits into the other information systems in the organization, or how it supports the business plan in general, you may be costing the organization more money than you realize. Did you just create an island of information that is incompatible with other systems, or is it fully supportive and easy utilized in other areas? The greatest advantage of the prototyping method of developing end-user interfaces is that users see the product, or at least a pretty good replica of it, right away. If they like it, you press on. If they don't like it, changes can be made immediately. There's less red tape and bureaucracy (perceived or otherwise) to work through in this method. But be careful if you use the prototype as the actual production version. Is it the best it can be, or are you just tired of fiddling around with it?
End-User DevelopmentTaking matters into their own hands. This method of system development is a bit like prototyping, but the end user designs and develops the new system using the fourth-generation language tools we previously reviewed. It's convenient for small applications, and the user can have complete ownership of the system. The tools available to the end user are getting easier to use all the time and increase the likelihood that the system will meet the user's specifications, since the user is building it. There's no one else to blame if the system doesn't do what the user wants it to do. But don't attempt to build larger and more complex systems using this method: The capabilities of the tools are limited. Managers should be aware of some inherent dangers when allowing users to develop their own systems. Standardization can be a tough issue when you use this method of system development. You're almost begging for conflicts in data processing and storage, since each user will have his or her own method of creating, defining, and developing data. The biggest danger is creating those islands of information. The chance of redundant end products just went up, since each user will have his or her own system with slight differences that may prohibit cross-utilization of the information. We're not trying to discourage this type of system development. As the text points out, the advantages of having users develop their own products are tremendous. You just need to be aware of the risks. One way to reduce some of the risks associated with this development process is to establish information centers in the organization. These are like technical support units that offer help and guidance to users. They can be the focal point for training, reviews, and advice. They can also ensure that systems meet certain organizational standards. Just don't make them too bureaucratic or difficult to access, because then no one will use them.
Application Software Development and OutsourcingWe mentioned earlier that software programs are becoming extremely complex to design, develop, and build. Many companies either don't have the in-house staff to accomplish the task or decide to focus on their core competencies and have someone else develop the software they need.
Application Software Packages Fast, easy, convenient, user-driven. Many software packages are extremely convenient for non-techies to use to develop their information products. Commonly called "off-the-shelf" software, these packages can be the best method of creating an information system if that system is fairly standard across different types of businesses. You don't have to worry about system documentation, since that usually comes with the software. You still have to write local procedures for using the program, but you don't have to start from scratch. Training is easier because once you learn how to use the menus and toolbars in one program, the same skills can be carried over to other programs. Training manuals often come with the program or are available through online help functions. Application software packages also provide an easier method of obtaining code corrections, updates, and enhancements: simply go to the Web site of the company that wrote the software and download the latest version. Need technical support for the program? Log on to the Web and you're there. No telephone calls, no waiting on hold for hours, no begging the IT staff to fix your problem. In fact, you'll probably find answers to questions you didn't even know you had! Most of the common programs still need to have standards for use within the organization. For instance, if you use an accounts receivable application software program, you should still set standards for how you will adapt that program to meet the unique requirements of your company. Most off-the-shelf software can't be changed, so you have to take what comes. The unique requirements of your organization probably won't be met. You'll end up having to change your methods to match the software, instead of the other way around. Some software packages do allow some customization, but not as much as a program developed solely for your organization. Application software packages still need lots of planning, especially when it comes to integrating them with the other information systems throughout the organization. Compatibility is key. You should determine the total cost of ownership with these programs beforehand. What are the training costs, implementation costs, and integration costs? They all add up. Selecting software packages can be just as demanding as developing a system on your own. You have to evaluate:
Just as you would for any piece of equipment, you would seek Requests for Proposal (RFP) from several vendors to fully evaluate the software package according to your needs. Remember, you give up a lot of control when you choose to go with a prewritten software package.
OutsourcingWhat happens if an organization decides it doesn't have the in-house expertise to support the system development process or any of the system maintenance required? No problem: outsource. There are hundreds of outside companies that will do the job. These companies offer expertise and experience, often at a lower cost than in-house staff. They can also offer smaller organizations economies of scale that make overall information processing cheaper. The total cost of ownership of a system can be cheaper because of outsourcing. Perhaps the outsourcing company can keep up with changing technologies better than the organization. It may simply be that the organization decides to spend in-house information resource dollars in other ways. Should you decide to use an outsourcing company to develop an information system, you must be more careful than ever to ensure that everything, right down to the smallest detail, is in writing and agreed upon by both sides. You are signing a contract with the outsourcer that carries the full force of law. You must agree on how changes will be made to the current system. How responsive will the outsourcer be to changing requirements? You still have some responsibilities for the system; what will they be? Get it in writing! You must continually analyze the outsourcing company's performance and cost and make sure it remains the cheaper, better way to handle the organization's needs. At some point in time, you may find a different method is in fact cheaper.
Table 14-6 gives a synopsis of each type of system development and helps you compare one to another.
14.5 Management Opportunities, Challenges, and SolutionsUntil a few years ago it was common for system development to take months if not years. That time frame has shortened to days or weeks. Pundits refer to "Internet time" as a reference for the much more rapid development of systems that some companies experience now. Unfortunately, some of the more important steps of development may be slighted or overlooked altogether in the rush to get a product out the door. Unfortunately, customers may be the ones to suffer the most from the mistakes.
OpportunitiesThe most demanding aspect of application development for the digital firm lies in the rapid expansion of the Internet. New uses for Web sites are introduced all the time and companies are challenged to accommodate the new technologies in their old processes. Customers and suppliers are constantly requesting new applications based on the Internet.
Management ChallengesThe systems development process for e-commerce and e-business concerns is more complicated because it may involve more entities than traditional processes. If an e-business process includes a firm's suppliers, the system may have to be designed and built with two different sets of requirements merged into one. Old systems were built for one or two types of computing devices. Now a firm must build its systems for desktops, laptops, cell phones, personal digital appliances, Web servers, mainframes, and even iPod-type devices. Software considerations are greater than at any time in the history of computing. Networked environments are now the norm.
New Interorganizational System Requirements We've discussed how digital firms now open their systems to a variety of users inside and outside the immediate organizational structure. From suppliers to customers to business partners, the digital firm must design and build information systems to meet a variety of users. This trend will only continue as networks take even greater precedence in the computing environment.
Solution GuidelinesDigital firms can't hold onto their old systems that fit requirements developed ten or even five years ago. Continual change, growth, and migration is required to remain competitive in today's business environment. New development processes that allow a firm to build systems to meet today's and tomorrow's requirements must be faster and easier than ever before.
Rapid Application Development (RAD) Supply and demand. The supply of technical specialists is not enough to support the demand for new systems, or maintenance of the old ones. Something has to fill the gap – that's why you see so many new methods already on the market and more advanced, easier-to-use tools coming down the road. The shortage of skilled technicians is also why you see more and more companies moving away from the structured methods we've reviewed. There just isn't enough time. Rapid Application Development (RAD) reduces the time it takes to build systems by using many of the tools that we've discussed. You can choose from prototyping or fourth-generation tools to develop systems much more quickly. End users and techies can work hand-in-hand with joint application design (JAD) tools to reduce the development time for new applications.
Component-Based Development Component-based development is simply the practice of developing reusable components that are commonly found in many software programs. Create a "Save File" function for one application and use it in all applications. Not only does it save development time but creates functions that users have to learn only once and use multiple times. In short, why keep re-inventing the wheel when it works just fine across a multitude of vehicles.
Web Services and Service-Oriented Computing The Internet and the Web provide the open standards that so many businesses and users now demand and were lacking from closed or proprietary systems. Advancing upon that openness is a new idea called Web services. The potential reward is untold savings in time and money and a major boost in productivity. Web services are based on industry standards so that all the services can speak to one another. That keeps companies from having to cope with pricey, proprietary software that can cost 10 times as much as Web service software. At the same time, companies are able to automate mundane tasks. "This is about automation – replacing manual processes with machine processes," says analyst Ted Schadler of Forrester Research Inc. "It's poised to revolutionize the way people solve business problems." BusinessWeek, e.biz, March 18, 2002
Discussion Questions:
|
