Nursing image petition and call for action assignment

Nursing image petition and call for action - Assignment Example The name of this character is Vivian Scully; this character appeared in eight episodes of the twelve episode season. Vivian Scully is student of nursing, and she is very ambitious, but her ambitions her limited to have a doctor husband, who is young, good looking, and rich. Throughout the first season the character of Vivian Scully is shown to be indulged into seducing Dr. Ethan Haas, who is young, talented and handsome. In reality â€Å"the nurse sustains a collaborative and respectful relationship with co-workers in nursing and other fields† (International Council of Nurses, 2012 p4). The show has however tied up the whole staff of the Washington University’s Hospital into a market of pleasure, which is quite objectionable, for people who are of a healthcare system, and those who respect these professionals. The purpose of media is to highlight the critical matters, and to make people aware about the truth (Spurr, Berry, & Walker, 2013). However, in entertainment industry there is little leverage that allows the artists to portray the world according to the theme that they have pictured in their minds. With the freedom of expression, there is also some duty on the artists, they must not create fiction that falsify the reality or put it upside down (Hoeve, Jansen, & Roodbol, 2014). Nursing is one of the professions that have suffered at the hands of movie directors, and script writers (Weaver, Salamonson, Koch, & Jackson, 2013). â€Å"The nurse at all times maintains standards of personal conduct which reflect well on the profession and enhance its image and public confidence†( International Council of Nurses, 2012 p 3). In movies and dramas however, nurses are portrayed as shallow creatures; the role Vivian Scully in one of the recent HBO’s productions i.e. The Masters of Sex has not done justice to the profession of nursing. I accept that professionals involved in nursing are not of the same mind set or caliber,

Application of ERP Implementation Methodology Framework

Application of ERP Implementation Methodology Framework Chapter 1 Introduction This chapter will begin with a presentation of the background of my research area. The presentation will thereafter be followed by a problem and Significance of the research that will result in the objective and research question of my study. Background Over the past years innovation has arguably become one of the most discussed and sought after organisation-capabilities. It is recognised as a major goal of economic activity and one of the most important instruments through which organisations can gain advantages over their competitors. In order to survive in highly competitive business environments, companies have to continuously change their business processes. New conditions in the marketplace have provided a special stimulus to modelling business processes: product expansion, competitive sales conditions, development of global distribution networks, better informed customers, and the orientation of businesses towards satisfying the individual needs of the customer. In the light of this, business process reengineering has often been employed, and information technology is a frequently utilised approach used to improve business processes. This study stressed the necessity for organisational restructuring in the context of global information connectivity. Business Process Reengineering is an organisational method demanding radical redesign of business processes in order to achieve greater efficiency, better quality and more competitive production (Hammer and Champy, 1993). It means analysing and altering the business processes of the organisation as a whole. A business process includes activities and tasks that cross functional and/or organisational boundaries. Information technology (IT) is the most important factor in enabling newly redesigned processes. Modern information technology is oriented towards business processes and communications between persons using these processes, and is therefore called process and information technology (Ould, 1995). In that way, Business Process Reengineering can be described as organisational process redesign, with the direct influence of IT. At the same time organisational expenditure on Enterprise Resource Planning (ERP) has also grown significantly during the 1990s and beyond. ERP systems have been adopted by the majority of large private sector organisations and many public sector organisations in the UK, Europe and the industrialised world in general. We would not expect this growing trend to materialise unless significant advantages were to be expected from the introduction of ERP systems. It is because ERP systems have such a significant impact on the organisation, the working practices of individuals and on human interaction that we wish to explore their impact on innovation. Origin of the term ERP In the 1960s, no manufacturing company could afford to own a computer. Therefore, both manufacturing and inventories were handled on the basis that companies must hold enough stocks to satisfy customer demand, and that customers would order what they had ordered in the past, quantity and time wise. There after manufacturing management systems have evolved in stages over the past 30 years from a simple means of calculating materials requirements to the automation of an entire enterprise. In the 1970s and 1980s, over-frequent changes in sales forecasts, entailing continual readjustments in production, as well as inflexible fixed system parameters, led material requirement planning (MRP) and master production schedule (MPS) to evolve into a new concept called manufacturing resource planning (MRPII) in 1980 (Kakouris Polychronopoulos, 2005). Finally in the early 1990s the generic concept Enterprise Resource Planning (ERP), incorporating all the MRPII functionality, in addition to Financ e, Supply Chain, Human Resources and Project Management functionality (Anderson, 1982; Wallace, 1986; Wilson et al., 1994). Figure1 illustrates the gradual evolution of the Enterprise Resource Planning with respect to time. Enterprise resource planning systems are commercial software packages that enable the integration of transaction-oriented data and business processes throughout an organisation (Markus and Tanis, 2000). The key elements of an Enterprise Resource Planning system according to Miller (2003) are: one large real-time database which reduces data redundancy and improves accuracy; integrated business process that cut across business functions such as supply chain management; and seamless transitions between business transactions. According to Newman (2003), Enterprise Resource Planning Systems are software modules for different business functions that are linked by a common database to produce an integrated enterprise-wide system. Enterprise Resource Planning packages, the enterprise system that makes company stick together, it is a nervous system of every corporation, large or small, when you check inside it tells whats going on, it helps you act as what nervous system do, how to react, to treat the information about competitors, about products, how do you get best out of it. It pays employees, makes billing, run accounts, interacts with customers, ships goods, basically it runs the process of any company and helps accelerate business innovation for your customers. They build process factories for enterprises, which are so flexible and configurable for the identical companies so that they can do different things with the same factories and Helping Companies Become Best-Run Businesses. ERP integrates key business and management functions and provides a view of the happenings in the company, in the areas of finance, human resources, manufacturing, supply chain, etc. (Davenport, 1998; James and Wolf, 2000). An ERP solution is valuable when it represents the characteristics demonstrated in Figure 2. Significance and objective of research In the 1990s, customers experienced more costly and complex ERP implementations then they expected (Eschinger et. al., 2003). One research group found that the average ERP implementation took 232 months, had a total cost of ownership of $15M, and rewarded the business with an average negative net present value of $1.5M (Wailgum, 2008). Because of their wide scope of application within a business, ERP software systems are typically complex and usually impose significant changes on staff work practices, Implementing ERP software system is typically not an in-house skill, so even smaller projects are more cost effective if specialist ERP implementation consultants are employed. The length of time to implement an ERP system depends on the size of the business, the scope of the change and willingness of the customer to take ownership for the project. A small project (e.g., a company of less than 100 staff) may be planned and delivered within 3-9 months; however, a large, multi-site or multi-country implementation may take years (for more details see table 1 and table 2). Although implementing an ERP system may be costly and time-consuming, its benefits are worthwhile. However, there are a number of examples where organisations have not been successful in reaping the potential benefits that motivated them to make large investments in ERP implementations (Davenport, 1998). The research is also predicting that ERP new license revenue will have fallen 24% in 2009, as companies severely rein back implementation and expansion projects. While the organisation expects ERP spending to rise slightly in 2010, vendors will be fighting hard for every available dollar, and that should translate into cost savings for customers (Kanaracus, 2010). Therefore year 2010 is predicted to be different and better in terms of ERP implementation. According to Langenwalter (2000), Enterprise Resource Planning implementation failure rate was from 40% to 60%, yet companies try to implement these systems because they are absolutely essential to responsive planning and communication (see Appendix 2 for ERP solution satisfaction). The competitive pressure unleashed by the process of globalisation is driving implementation of Enterprise Resource Planning projects in increasingly large numbers, so methodological framework for dealing with complex problem of evaluating Enterprise Resource Planning projects is required (Teltumbde, 2000). All ERP vendors came up with solution and build their implementation methodology which they recommend to all their clients to utilise the approach during their implementation and continuously looking for improvements in those methods. Therefore the Research in this subject will value the investment put in by the companies in these projects. The primary objective of this dissertation was to explore the application of ERP implementation methodology framework by different vendors when implementing ERP and to find commonalities or diversion in the ways of improvement by them. Therefore the key research questions that are the focus of this study are: To what extent different companies follow AcceleratedSAP as methodology when implementing SAP? Is different companies use different innovative ways to improve the process? Are there commonalities or diversion in this innovation? Chapter 2 Literature Review The purpose of this chapter is to present my theoretical framework. In this chapter first I will present different implementation framework models from some researchers and academician. Then select one model as my theoretical base. Information Systems Development Methodology Creation of an Information System is not a trivial matter, and must strive to fulfil four main goals; usefulness, usability, reliability and flexibility (Kruchten, 2000). To minimise risks of failure in any of these primary objectives there are a number of specialised development methodologies available, each with different strengths and weaknesses and suited to different project types: The Classic Model This model, often called the Waterfall model (figure 3), represents the traditional software lifecycle, and outlines an Information System project in clearly defined, partitioned phases that follow in sequential order (though the actual phases are not always the same) (Avgerou and Cornford, 1998). This approach has strengths when requirements are well known and unchanging, unfortunately problems with this approach are quickly identified. The main failings of this model stem from its linear nature, where each stage must be completed and the outputted deliverable passed to the next phase. This produces an inflexible model that is hard to step back to previous stages without changing everything (Avison and Fitzgerald, 2006). Due to this separated structure a gap of understanding can become present between users and developers, and as no deliverables are viewed until the end of the sequence unsatisfactory results can be delivered. It also typically suffers from long development times (wh ich are certainly not available in this project) and as such is not usually practised in the formal fashion (Avgerou and Cornford, 1998). This model alone is clearly unsuitable to the ERP implementation project as completion in a timely fashion is a key objective, and with this extra constraint risks will be extremely high. As such requirements capture/analysis will need to on-going throughout the entire process. With these points noted, a partially phased approach is attractive from a project management point of view, and an extensive initial requirements capture phase could greatly reduce project risks through understanding of the problem domain. Business Process Reengineering Implementing Methodologies One approach of information system development, which takes into account strategic aspects, is business process reengineering. It has presented organisation with the opportunity to rethink out dated procedures, rules, and assumptions underlying their business activities. This opportunity is usually enabled partly by the application of technology to outdated process (Avison and Fitzgerald, 2006). The initial research of the subject starts with Business Process Reengineering which is achieved by the adoption of ERP as it streamline the organisations processes by integrating the information flow into a single system. The term business process reengineering had its origin at MIT during 1984-1989 while MITs enumerating management techniques for the 1990s. Business process reengineering simply means transformation from function based to process based. The radical redesign of a process is easily achieved by involving information technology (IT) in business processes and hence the prominence of IT in business process reengineering. IT is accepted not only as just a business process reengineering enabler (Hammer and Champy, 1993) but also as an essential enabler of business process reengineering (Davenport and Short, 1998). There exists a recursive relationship between business process reengineering and IT which can be utilised for thorough process change. In the modern times and due to rapid proliferation of computers in the business arena, business process reengineering through IT is getting a big boost. Business process reengineering using IT emanated from gradual progression in the use of computers from routine clerical job processing to IT-based decision making. Many corporations reaped benefits by re-engineering their processes at various stages of IT development. At the same time, re-engineering cannot be planned and achieved in small cautious steps for any corporation (Hammer, 1990). Some of the commonly used IT tools for re-engineering are ERP systems. First we adopt the work of Kettinger al.s (1997) for a literature review on business process reengineering implementing methodologies also chosen by Pellerin and Hadaya (2008). This implementation methodology proposes a generic stage-activity framework for conducting business process reengineering projects, because The technology is derived from the methodologies practiced by 25 leading reengineering consulting organisations and Unlike most business process reengineering studies, in which the unit of analysis is the organisation, Kettinger et al.s (1997) work is cantered on the business process reengineering project, which is more relevant to Information System professionals. Kettinger et al.s (1997) framework comprises six stages, each containing the following activities (See Figure 4). The first stage, envision (S1), typically involves the business process reengineering project champion engendering the support of the top management. A task force, including senior executives and individuals knowledgeable about an organisations processes, is authorised to target a business process for improvement based on a review of business strategy and IT opportunities in the hope of improving the organisations overall performance. The second stage, initiate (S2), encompasses the assignment of a reengineering project team, setting of the performance goals, project planning and shareholder/employee notification and buy-in. This is frequently achieved by developing a business case for reengineering via bench-marking, identifying external customer needs, and cost benefit analysis. The third stage, diagnose (S3), is classified as the documentation of the current process and sub processes in terms of process attributes such as activities, resources, communication, roles, IT, and cost. In identifying process requirements and assigning customers value, root causes for the problems are surfaced, and non-value-adding activities are identified. The fourth stage, redesign (S4), a new process design is developed. This is accomplished by devising process design alternatives through brainstorming and creativity techniques. The new design should meet strategic objective and fit with the human resource and IT architecture. Documentation and prototyping of the new process is typically conducted, and a design of new information system to support the new process is completed. The fifth stage, reconstruct (S5), heavily relies on change management techniques to ensure smooth migration to new process responsibilities and human resources roles. During this stage, the IT platform and systems are implemented, and the users go through the training and transition. The sixth and last stage, evaluate (S6), requires monitoring of the new process to determine if it met its goal and often involves linkage to an organisations total quality program. This methodology was empirically derived from the methodologies practiced by 25 leading reengineering consulting firms which takes the management accounting perspective by attempting to reorganise business processes while using information as an enabler then it provides a set of tools and techniques to facilitate the reengineering effort and unlike most BPR studies, in which the unit of analysis is the organisation (Kettinger et al., 1997; Pellerin and Hadaya, 2008). This justifies the use of this methodology to build on the relation of further theories but just to compare and have further opinion let look at another business process reengineering implementation methodology. A seven-step methodology, as shown in Figure 5, that shows the various steps in IT driven business process reengineering implementation (Davenport and Short, 1998; Armistead and Rowland, 1996). These steps are prioritising processes based on the comparative importance of objectives, identifying the processes to be redesigned, understanding and measuring/benchmarking the existing processes, identifying the appropriate IT tool, designing/building a process prototype, testing the reengineered process, and implementing the changed process. The first step is to define the objectives of the process redesign which can be cost reduction, time reduction, improvement in output quality and/or improvement of quality of work life. Rarely, organisations become successful in meeting multiple objectives, concurrently. In the second step, selection of the processes to be redesigned is carried out. The two approaches, namely, exhaustive and high-impact approaches are available for the selection of the processes to be redesigned. Exhaustive approach ranks all processes to be redesigned based on the order of urgency prior to the identification of the process to be redesigned whereas the high-impact approach tries to identify only the most important processes which are in conflict with business vision and process objectives. The third step tries to measure the process before redesign in order to avoid repetition and to set a baseline for future improvements. In the fourth step, it is better to have a picture of all latest IT technologi es available for redesign prior to the redesign and freezing of the redesigned process under study. The fifth step can be easily dealt with by using IT as a design tool in creating a more generic design of the process under study in arriving at a suitable organisational prototype. After generating the redesigned process prototype, implement the same in one of the units of the organisation to study the actual benefits before launching it on an organisation wide basis and the same is done in the sixth step. If the pilot launch is found successful in meeting the process objectives, launch the redesigned process throughout the organisation which is the seventh and last step in IT-based implementation of the redesigned process. If both the implementation methodologies are compared there is not just the difference in number of steps between the two methodologies, there is also the difference in the approach in cut-overs where training of users are missing in second as well the pilots and rollouts are mentioned in the later methodology. This goes with Kettinger et als (1997) findings that, while business process reengineering implementing methodologies may vary based on philosophical differences, there is enough commonality among the practiced approaches to generally describe a prototypical business process reengineering efforts. Generic Enterprise Resource Planning Implementing Methodologies In the past, companies used to decide how they wanted to do business and then made a decision about a software package that best supported their business processes. This was changed with ERP systems that required the business processes to be modified to fit the system (Davenport, 1998). Business Process Reengineering implementation exists ranging from technology enabled re-engineering to clean slate re-engineering. If ERP system is chosen first, then the re-engineering is driven by the chosen ERP system or re-engineering is technology enabled. The reason why many companies chose to conduct ERP system development was to attempt to solve all their organisational problems without reengineering business processes first. Then the Costs involved with such re-engineering are very low as alteration done on the system is least or none. In clean slate re-engineering, design starts from scratch and ERP system software is highly customised to fit the processes of the enterprise in discussion. ERP implementation significantly impacts company culture, organisational structure, business processes, in addition to procedures and rules. Furthermore, ERP applications integrate many best business practices and much knowledge that could be worthwhile if included as a part of BPR projects. By taking the best practices inherent in ERP applications, companies can change their processes simultaneously with technological change. As a result, many companies changed their business processes to fit the ERP system requirements, and the possibilities of ERP systems have been used to underpin Business Process Reengineering (Kooch, 2001, Chenn, 2001). As ERP systems have traditionally taken too long to implement, a dynamic and incremental implementation of ERP components is recommended as opposed to massive reengineering. Also pointed by Ahmed (1999) the focus of ERP implementations has shifted from matching business processes with the ERP system to developing knowledge-workers that can quickly understand and work with redesigned processes and realise the ERP-enabled benefits. Boudreau and Robey (2005), suggest a vital importance to acceptance of ERP systems. They also note that if not successfully implemented, users may work around the system and otherwise doom the project to costly duplication of effort, or worse, system failure. A phased implementation approach is highlighted in Robey et al. (2002). It is important to have a structured approach, similar to systems development, for the implementation and maintenance of ERP systems. Systems development theory uses the concept of a lifecycle and stages in the lifecycle to indicate development of information systems. The waterfall model, incremental model, RAD (rapid application development) model and spiral model are some of the systems development methods prevalent in the literature. Newer approaches to systems development address component-based development using off-the-shelf packages, agile development and the unified process for object-oriented software development (Pressman, 2005). The newer approaches have fewer stages in the development of systems. For example, the unified process which draws upon the best practices of conventional software process models has inception, elaboration, construction and transition phases. A common aspect of all these models is that they focus little attention on implementation and the post implementation of the system. The literature review undertaken revealed a lack of research with regard to some critical factors of ERP implementation (eg client consultation, schedule and plans), and this could be due to the fact that these factors are related to any information system project, not particularly to ERP project implementation. However, and generally speaking, there has not yet been a common comprehensive or integrative approach to ERP implementation. Successful ERP project implementation is a complex and difficult task. Implementing an ERP system package causes vast change that needs to be managed carefully to get the full advantages (Bingi et al, 1999; Sor, 1999). More importantly, it has been stressed by many that it is really a mistake to view ERP project implementation as merely an IT project (Davenport, 2000; Milford Stewart, 2000; OLeary, 2000). A major difference between ERP systems and traditional information systems comes from the integrated nature of ERP applications. Implementing an ERP system causes dramatic changes that need to be carefully administrated to reap the advantages of an ERP solution. Holland and Light (1999) cite that the implementation of an ERP software package involves a mix of business process change and software configuration to align the software with the business processes. In that sense, it has become clear through the literature review, and studying the experiences of leading organisations, that the implementation of an ERP system is radically different from traditional systems development. In an ERP system implementation, the key focus has shifted from a heavy emphasis on technical analysis and programming towards business process design, business-focused software configuration (Kelly et al, 1999), and legacy data clean-up (Smethurst Kawalek, 1999). In essence, there are several critical and inter-related issues that must be carefully considered to ensure successful implementation of an ERP system project. The framework (Figure 6) presented in this report is the result a major research study undertaken to propose an integrative Critical Success Factors view of ERP. ERP system implementation has been subdivided into three levels: strategic, tactical, and operational. Each level contains a number of critical factors. These levels of implementation, however, are not independent of each other, and each level should be used to derive the next level. Moreover, each level requires differing inputs; for example, there is a direct relationship between the implementation level at which a decision is being taken and the characteristics of the information required supporting decision making (Bocij et al, 2008). Communication Communication is one of most challenging and difficult tasks in any ERP implementation project (Welti, 1999). Slevin and Pinto (1987) define communication as the provision of an appropriate network and necessary data to all key factors in the project implementation. Communication has to cover the scope, objectives, and tasks of an ERP implementation project (Sumner, 1999). Failure to establish and manage the communication process with stakeholders can lead to a lack of support from stakeholders, disapproval of the deliverables and dissatisfaction. ERP implementation levels Strategic level The decisions made at this level significantly change the manner in which business is being done (Bocij et al, 2008), and these decisions are the responsibility of top management (Schultheis Sumner, 1995; Turban et al, 2000). This level can be considered as the process of establishing overall goals and of planning how to achieve those goals. Kelly et al (1999) suggested that the strategic level is the premeditated plan for transforming the organisation, enabling it to operate in the new style environment. Current legacy system evaluation: This includes the existing IT (hardware and software), business processes, organisation structure, and culture. Holland and Light (1999) argue that the nature and scale of problems that are likely to be encountered can be defined by evaluating the existing legacy system (by asking what the status of the enterprises legacy system is and how it will affect the transition to ERP and common business processes). It is clear that ERP implementation involves a complex transition from legacy information systems and business processes to an integrated IT infrastructure and common business process throughout the organisation (Gibson et al, 1999). Project vision and objective: It is very important that the organisation has a clear sense of whom and what it is before implementing an ERP project (Davenport, 2000). A global survey showed that an understanding of business objectives and clear vision are key success factors (Cooke Peterson, 1998). Slevin and Pinto (1987) define project vision as the initial clarity of goals and general direction. Welti (1999) advises on determining the project vision in the planning phase, particularly within the project scope, where the project scope includes the project definition, objectives, and strategy. He argues that all these components of the project scope are compulsory to create a clear project vision. At this stage in the ERP project, the vision should provide a direction and general objective, and no details are required. ERP implementation strategy: This will be reviewed in this level to determine the impact of ERP system implementation on the enterprise. Trepper (1999) argues that the organisations executive managers must understand how ERP system implementation will impact on the organisation to ensure a smooth transition. Holland and Light (1999) suggest that the propensity of an organisation for change should influence the choice of ERP implementation project strategy. There are two main technical options to implement an ERP system: modify the ERP system package to suit an organisations requirements or the implementation of a standard package with minimum deviation from the standard settings. Companies that do not select the second option are liable to face major difficulties (Bancroft et al, 1998; Martin, 1998; Gibson et al, 1999). Hiring consultants: Due to the complexities of implementing an ERP system, most companies choose to hire consultants to help them select, configure, and implement the system. Welti (1999) argues that the success of a project depends on the capabilities of the consultants, because they have in-depth knowledge of the software. Somers and Nelson (2001) point out those consultants may be involved in different stages of the ERP project implementation. There are hundreds of companies that provide such ERP services. Since it is a critical success factor, it has to be managed and monitored very carefully. Benchmarking: Al-Mashari and Zairi (2000) argue that benchmarking works essentially at capturing both external and internal best practices related to all aspects of ERP system implementation, and enabling the transfer of knowledge across all levels of project implementation. They argue that benchmarking can play a significant role in shaping the strategic direction to be taken for change introduction using an ERP package. Tactical level At the tactical level, also termed managerial level, the medium-term planning of ERP specific organisational issues is largely concerned, where decisions are made by middle managers (Turban et al, 2000). In order to make sure that the enterprise is meeting its targets, objectives of top management are accomplished, and it is not wasting its resources, the tactical level provides middle-level managers with the information they need to monitor the performance of the organisation, control operations, and allocate resources and set policies effectively (Schultheis Sumner, 1995; Bocij et al, 2008). Client consultation: Slevin and Pinto (1987) define client consultation as the communication and consultation with, and active listening to all affected parties, mainly the client. It is essential for an organisation to keep its clients aware of its future project to avoid misconception. They also argued that the consultation with clients should occur early in the process; otherwise the chance of subsequent client acceptance will be lowered. In general, this factor has not been thoroughly discussed in the literature reviewed. Business process change (BPC): As mentioned before, there are two main options to implement ERP syst Application of ERP Implementation Methodology Framework Application of ERP Implementation Methodology Framework Chapter 1 Introduction This chapter will begin with a presentation of the background of my research area. The presentation will thereafter be followed by a problem and Significance of the research that will result in the objective and research question of my study. Background Over the past years innovation has arguably become one of the most discussed and sought after organisation-capabilities. It is recognised as a major goal of economic activity and one of the most important instruments through which organisations can gain advantages over their competitors. In order to survive in highly competitive business environments, companies have to continuously change their business processes. New conditions in the marketplace have provided a special stimulus to modelling business processes: product expansion, competitive sales conditions, development of global distribution networks, better informed customers, and the orientation of businesses towards satisfying the individual needs of the customer. In the light of this, business process reengineering has often been employed, and information technology is a frequently utilised approach used to improve business processes. This study stressed the necessity for organisational restructuring in the context of global information connectivity. Business Process Reengineering is an organisational method demanding radical redesign of business processes in order to achieve greater efficiency, better quality and more competitive production (Hammer and Champy, 1993). It means analysing and altering the business processes of the organisation as a whole. A business process includes activities and tasks that cross functional and/or organisational boundaries. Information technology (IT) is the most important factor in enabling newly redesigned processes. Modern information technology is oriented towards business processes and communications between persons using these processes, and is therefore called process and information technology (Ould, 1995). In that way, Business Process Reengineering can be described as organisational process redesign, with the direct influence of IT. At the same time organisational expenditure on Enterprise Resource Planning (ERP) has also grown significantly during the 1990s and beyond. ERP systems have been adopted by the majority of large private sector organisations and many public sector organisations in the UK, Europe and the industrialised world in general. We would not expect this growing trend to materialise unless significant advantages were to be expected from the introduction of ERP systems. It is because ERP systems have such a significant impact on the organisation, the working practices of individuals and on human interaction that we wish to explore their impact on innovation. Origin of the term ERP In the 1960s, no manufacturing company could afford to own a computer. Therefore, both manufacturing and inventories were handled on the basis that companies must hold enough stocks to satisfy customer demand, and that customers would order what they had ordered in the past, quantity and time wise. There after manufacturing management systems have evolved in stages over the past 30 years from a simple means of calculating materials requirements to the automation of an entire enterprise. In the 1970s and 1980s, over-frequent changes in sales forecasts, entailing continual readjustments in production, as well as inflexible fixed system parameters, led material requirement planning (MRP) and master production schedule (MPS) to evolve into a new concept called manufacturing resource planning (MRPII) in 1980 (Kakouris Polychronopoulos, 2005). Finally in the early 1990s the generic concept Enterprise Resource Planning (ERP), incorporating all the MRPII functionality, in addition to Financ e, Supply Chain, Human Resources and Project Management functionality (Anderson, 1982; Wallace, 1986; Wilson et al., 1994). Figure1 illustrates the gradual evolution of the Enterprise Resource Planning with respect to time. Enterprise resource planning systems are commercial software packages that enable the integration of transaction-oriented data and business processes throughout an organisation (Markus and Tanis, 2000). The key elements of an Enterprise Resource Planning system according to Miller (2003) are: one large real-time database which reduces data redundancy and improves accuracy; integrated business process that cut across business functions such as supply chain management; and seamless transitions between business transactions. According to Newman (2003), Enterprise Resource Planning Systems are software modules for different business functions that are linked by a common database to produce an integrated enterprise-wide system. Enterprise Resource Planning packages, the enterprise system that makes company stick together, it is a nervous system of every corporation, large or small, when you check inside it tells whats going on, it helps you act as what nervous system do, how to react, to treat the information about competitors, about products, how do you get best out of it. It pays employees, makes billing, run accounts, interacts with customers, ships goods, basically it runs the process of any company and helps accelerate business innovation for your customers. They build process factories for enterprises, which are so flexible and configurable for the identical companies so that they can do different things with the same factories and Helping Companies Become Best-Run Businesses. ERP integrates key business and management functions and provides a view of the happenings in the company, in the areas of finance, human resources, manufacturing, supply chain, etc. (Davenport, 1998; James and Wolf, 2000). An ERP solution is valuable when it represents the characteristics demonstrated in Figure 2. Significance and objective of research In the 1990s, customers experienced more costly and complex ERP implementations then they expected (Eschinger et. al., 2003). One research group found that the average ERP implementation took 232 months, had a total cost of ownership of $15M, and rewarded the business with an average negative net present value of $1.5M (Wailgum, 2008). Because of their wide scope of application within a business, ERP software systems are typically complex and usually impose significant changes on staff work practices, Implementing ERP software system is typically not an in-house skill, so even smaller projects are more cost effective if specialist ERP implementation consultants are employed. The length of time to implement an ERP system depends on the size of the business, the scope of the change and willingness of the customer to take ownership for the project. A small project (e.g., a company of less than 100 staff) may be planned and delivered within 3-9 months; however, a large, multi-site or multi-country implementation may take years (for more details see table 1 and table 2). Although implementing an ERP system may be costly and time-consuming, its benefits are worthwhile. However, there are a number of examples where organisations have not been successful in reaping the potential benefits that motivated them to make large investments in ERP implementations (Davenport, 1998). The research is also predicting that ERP new license revenue will have fallen 24% in 2009, as companies severely rein back implementation and expansion projects. While the organisation expects ERP spending to rise slightly in 2010, vendors will be fighting hard for every available dollar, and that should translate into cost savings for customers (Kanaracus, 2010). Therefore year 2010 is predicted to be different and better in terms of ERP implementation. According to Langenwalter (2000), Enterprise Resource Planning implementation failure rate was from 40% to 60%, yet companies try to implement these systems because they are absolutely essential to responsive planning and communication (see Appendix 2 for ERP solution satisfaction). The competitive pressure unleashed by the process of globalisation is driving implementation of Enterprise Resource Planning projects in increasingly large numbers, so methodological framework for dealing with complex problem of evaluating Enterprise Resource Planning projects is required (Teltumbde, 2000). All ERP vendors came up with solution and build their implementation methodology which they recommend to all their clients to utilise the approach during their implementation and continuously looking for improvements in those methods. Therefore the Research in this subject will value the investment put in by the companies in these projects. The primary objective of this dissertation was to explore the application of ERP implementation methodology framework by different vendors when implementing ERP and to find commonalities or diversion in the ways of improvement by them. Therefore the key research questions that are the focus of this study are: To what extent different companies follow AcceleratedSAP as methodology when implementing SAP? Is different companies use different innovative ways to improve the process? Are there commonalities or diversion in this innovation? Chapter 2 Literature Review The purpose of this chapter is to present my theoretical framework. In this chapter first I will present different implementation framework models from some researchers and academician. Then select one model as my theoretical base. Information Systems Development Methodology Creation of an Information System is not a trivial matter, and must strive to fulfil four main goals; usefulness, usability, reliability and flexibility (Kruchten, 2000). To minimise risks of failure in any of these primary objectives there are a number of specialised development methodologies available, each with different strengths and weaknesses and suited to different project types: The Classic Model This model, often called the Waterfall model (figure 3), represents the traditional software lifecycle, and outlines an Information System project in clearly defined, partitioned phases that follow in sequential order (though the actual phases are not always the same) (Avgerou and Cornford, 1998). This approach has strengths when requirements are well known and unchanging, unfortunately problems with this approach are quickly identified. The main failings of this model stem from its linear nature, where each stage must be completed and the outputted deliverable passed to the next phase. This produces an inflexible model that is hard to step back to previous stages without changing everything (Avison and Fitzgerald, 2006). Due to this separated structure a gap of understanding can become present between users and developers, and as no deliverables are viewed until the end of the sequence unsatisfactory results can be delivered. It also typically suffers from long development times (wh ich are certainly not available in this project) and as such is not usually practised in the formal fashion (Avgerou and Cornford, 1998). This model alone is clearly unsuitable to the ERP implementation project as completion in a timely fashion is a key objective, and with this extra constraint risks will be extremely high. As such requirements capture/analysis will need to on-going throughout the entire process. With these points noted, a partially phased approach is attractive from a project management point of view, and an extensive initial requirements capture phase could greatly reduce project risks through understanding of the problem domain. Business Process Reengineering Implementing Methodologies One approach of information system development, which takes into account strategic aspects, is business process reengineering. It has presented organisation with the opportunity to rethink out dated procedures, rules, and assumptions underlying their business activities. This opportunity is usually enabled partly by the application of technology to outdated process (Avison and Fitzgerald, 2006). The initial research of the subject starts with Business Process Reengineering which is achieved by the adoption of ERP as it streamline the organisations processes by integrating the information flow into a single system. The term business process reengineering had its origin at MIT during 1984-1989 while MITs enumerating management techniques for the 1990s. Business process reengineering simply means transformation from function based to process based. The radical redesign of a process is easily achieved by involving information technology (IT) in business processes and hence the prominence of IT in business process reengineering. IT is accepted not only as just a business process reengineering enabler (Hammer and Champy, 1993) but also as an essential enabler of business process reengineering (Davenport and Short, 1998). There exists a recursive relationship between business process reengineering and IT which can be utilised for thorough process change. In the modern times and due to rapid proliferation of computers in the business arena, business process reengineering through IT is getting a big boost. Business process reengineering using IT emanated from gradual progression in the use of computers from routine clerical job processing to IT-based decision making. Many corporations reaped benefits by re-engineering their processes at various stages of IT development. At the same time, re-engineering cannot be planned and achieved in small cautious steps for any corporation (Hammer, 1990). Some of the commonly used IT tools for re-engineering are ERP systems. First we adopt the work of Kettinger al.s (1997) for a literature review on business process reengineering implementing methodologies also chosen by Pellerin and Hadaya (2008). This implementation methodology proposes a generic stage-activity framework for conducting business process reengineering projects, because The technology is derived from the methodologies practiced by 25 leading reengineering consulting organisations and Unlike most business process reengineering studies, in which the unit of analysis is the organisation, Kettinger et al.s (1997) work is cantered on the business process reengineering project, which is more relevant to Information System professionals. Kettinger et al.s (1997) framework comprises six stages, each containing the following activities (See Figure 4). The first stage, envision (S1), typically involves the business process reengineering project champion engendering the support of the top management. A task force, including senior executives and individuals knowledgeable about an organisations processes, is authorised to target a business process for improvement based on a review of business strategy and IT opportunities in the hope of improving the organisations overall performance. The second stage, initiate (S2), encompasses the assignment of a reengineering project team, setting of the performance goals, project planning and shareholder/employee notification and buy-in. This is frequently achieved by developing a business case for reengineering via bench-marking, identifying external customer needs, and cost benefit analysis. The third stage, diagnose (S3), is classified as the documentation of the current process and sub processes in terms of process attributes such as activities, resources, communication, roles, IT, and cost. In identifying process requirements and assigning customers value, root causes for the problems are surfaced, and non-value-adding activities are identified. The fourth stage, redesign (S4), a new process design is developed. This is accomplished by devising process design alternatives through brainstorming and creativity techniques. The new design should meet strategic objective and fit with the human resource and IT architecture. Documentation and prototyping of the new process is typically conducted, and a design of new information system to support the new process is completed. The fifth stage, reconstruct (S5), heavily relies on change management techniques to ensure smooth migration to new process responsibilities and human resources roles. During this stage, the IT platform and systems are implemented, and the users go through the training and transition. The sixth and last stage, evaluate (S6), requires monitoring of the new process to determine if it met its goal and often involves linkage to an organisations total quality program. This methodology was empirically derived from the methodologies practiced by 25 leading reengineering consulting firms which takes the management accounting perspective by attempting to reorganise business processes while using information as an enabler then it provides a set of tools and techniques to facilitate the reengineering effort and unlike most BPR studies, in which the unit of analysis is the organisation (Kettinger et al., 1997; Pellerin and Hadaya, 2008). This justifies the use of this methodology to build on the relation of further theories but just to compare and have further opinion let look at another business process reengineering implementation methodology. A seven-step methodology, as shown in Figure 5, that shows the various steps in IT driven business process reengineering implementation (Davenport and Short, 1998; Armistead and Rowland, 1996). These steps are prioritising processes based on the comparative importance of objectives, identifying the processes to be redesigned, understanding and measuring/benchmarking the existing processes, identifying the appropriate IT tool, designing/building a process prototype, testing the reengineered process, and implementing the changed process. The first step is to define the objectives of the process redesign which can be cost reduction, time reduction, improvement in output quality and/or improvement of quality of work life. Rarely, organisations become successful in meeting multiple objectives, concurrently. In the second step, selection of the processes to be redesigned is carried out. The two approaches, namely, exhaustive and high-impact approaches are available for the selection of the processes to be redesigned. Exhaustive approach ranks all processes to be redesigned based on the order of urgency prior to the identification of the process to be redesigned whereas the high-impact approach tries to identify only the most important processes which are in conflict with business vision and process objectives. The third step tries to measure the process before redesign in order to avoid repetition and to set a baseline for future improvements. In the fourth step, it is better to have a picture of all latest IT technologi es available for redesign prior to the redesign and freezing of the redesigned process under study. The fifth step can be easily dealt with by using IT as a design tool in creating a more generic design of the process under study in arriving at a suitable organisational prototype. After generating the redesigned process prototype, implement the same in one of the units of the organisation to study the actual benefits before launching it on an organisation wide basis and the same is done in the sixth step. If the pilot launch is found successful in meeting the process objectives, launch the redesigned process throughout the organisation which is the seventh and last step in IT-based implementation of the redesigned process. If both the implementation methodologies are compared there is not just the difference in number of steps between the two methodologies, there is also the difference in the approach in cut-overs where training of users are missing in second as well the pilots and rollouts are mentioned in the later methodology. This goes with Kettinger et als (1997) findings that, while business process reengineering implementing methodologies may vary based on philosophical differences, there is enough commonality among the practiced approaches to generally describe a prototypical business process reengineering efforts. Generic Enterprise Resource Planning Implementing Methodologies In the past, companies used to decide how they wanted to do business and then made a decision about a software package that best supported their business processes. This was changed with ERP systems that required the business processes to be modified to fit the system (Davenport, 1998). Business Process Reengineering implementation exists ranging from technology enabled re-engineering to clean slate re-engineering. If ERP system is chosen first, then the re-engineering is driven by the chosen ERP system or re-engineering is technology enabled. The reason why many companies chose to conduct ERP system development was to attempt to solve all their organisational problems without reengineering business processes first. Then the Costs involved with such re-engineering are very low as alteration done on the system is least or none. In clean slate re-engineering, design starts from scratch and ERP system software is highly customised to fit the processes of the enterprise in discussion. ERP implementation significantly impacts company culture, organisational structure, business processes, in addition to procedures and rules. Furthermore, ERP applications integrate many best business practices and much knowledge that could be worthwhile if included as a part of BPR projects. By taking the best practices inherent in ERP applications, companies can change their processes simultaneously with technological change. As a result, many companies changed their business processes to fit the ERP system requirements, and the possibilities of ERP systems have been used to underpin Business Process Reengineering (Kooch, 2001, Chenn, 2001). As ERP systems have traditionally taken too long to implement, a dynamic and incremental implementation of ERP components is recommended as opposed to massive reengineering. Also pointed by Ahmed (1999) the focus of ERP implementations has shifted from matching business processes with the ERP system to developing knowledge-workers that can quickly understand and work with redesigned processes and realise the ERP-enabled benefits. Boudreau and Robey (2005), suggest a vital importance to acceptance of ERP systems. They also note that if not successfully implemented, users may work around the system and otherwise doom the project to costly duplication of effort, or worse, system failure. A phased implementation approach is highlighted in Robey et al. (2002). It is important to have a structured approach, similar to systems development, for the implementation and maintenance of ERP systems. Systems development theory uses the concept of a lifecycle and stages in the lifecycle to indicate development of information systems. The waterfall model, incremental model, RAD (rapid application development) model and spiral model are some of the systems development methods prevalent in the literature. Newer approaches to systems development address component-based development using off-the-shelf packages, agile development and the unified process for object-oriented software development (Pressman, 2005). The newer approaches have fewer stages in the development of systems. For example, the unified process which draws upon the best practices of conventional software process models has inception, elaboration, construction and transition phases. A common aspect of all these models is that they focus little attention on implementation and the post implementation of the system. The literature review undertaken revealed a lack of research with regard to some critical factors of ERP implementation (eg client consultation, schedule and plans), and this could be due to the fact that these factors are related to any information system project, not particularly to ERP project implementation. However, and generally speaking, there has not yet been a common comprehensive or integrative approach to ERP implementation. Successful ERP project implementation is a complex and difficult task. Implementing an ERP system package causes vast change that needs to be managed carefully to get the full advantages (Bingi et al, 1999; Sor, 1999). More importantly, it has been stressed by many that it is really a mistake to view ERP project implementation as merely an IT project (Davenport, 2000; Milford Stewart, 2000; OLeary, 2000). A major difference between ERP systems and traditional information systems comes from the integrated nature of ERP applications. Implementing an ERP system causes dramatic changes that need to be carefully administrated to reap the advantages of an ERP solution. Holland and Light (1999) cite that the implementation of an ERP software package involves a mix of business process change and software configuration to align the software with the business processes. In that sense, it has become clear through the literature review, and studying the experiences of leading organisations, that the implementation of an ERP system is radically different from traditional systems development. In an ERP system implementation, the key focus has shifted from a heavy emphasis on technical analysis and programming towards business process design, business-focused software configuration (Kelly et al, 1999), and legacy data clean-up (Smethurst Kawalek, 1999). In essence, there are several critical and inter-related issues that must be carefully considered to ensure successful implementation of an ERP system project. The framework (Figure 6) presented in this report is the result a major research study undertaken to propose an integrative Critical Success Factors view of ERP. ERP system implementation has been subdivided into three levels: strategic, tactical, and operational. Each level contains a number of critical factors. These levels of implementation, however, are not independent of each other, and each level should be used to derive the next level. Moreover, each level requires differing inputs; for example, there is a direct relationship between the implementation level at which a decision is being taken and the characteristics of the information required supporting decision making (Bocij et al, 2008). Communication Communication is one of most challenging and difficult tasks in any ERP implementation project (Welti, 1999). Slevin and Pinto (1987) define communication as the provision of an appropriate network and necessary data to all key factors in the project implementation. Communication has to cover the scope, objectives, and tasks of an ERP implementation project (Sumner, 1999). Failure to establish and manage the communication process with stakeholders can lead to a lack of support from stakeholders, disapproval of the deliverables and dissatisfaction. ERP implementation levels Strategic level The decisions made at this level significantly change the manner in which business is being done (Bocij et al, 2008), and these decisions are the responsibility of top management (Schultheis Sumner, 1995; Turban et al, 2000). This level can be considered as the process of establishing overall goals and of planning how to achieve those goals. Kelly et al (1999) suggested that the strategic level is the premeditated plan for transforming the organisation, enabling it to operate in the new style environment. Current legacy system evaluation: This includes the existing IT (hardware and software), business processes, organisation structure, and culture. Holland and Light (1999) argue that the nature and scale of problems that are likely to be encountered can be defined by evaluating the existing legacy system (by asking what the status of the enterprises legacy system is and how it will affect the transition to ERP and common business processes). It is clear that ERP implementation involves a complex transition from legacy information systems and business processes to an integrated IT infrastructure and common business process throughout the organisation (Gibson et al, 1999). Project vision and objective: It is very important that the organisation has a clear sense of whom and what it is before implementing an ERP project (Davenport, 2000). A global survey showed that an understanding of business objectives and clear vision are key success factors (Cooke Peterson, 1998). Slevin and Pinto (1987) define project vision as the initial clarity of goals and general direction. Welti (1999) advises on determining the project vision in the planning phase, particularly within the project scope, where the project scope includes the project definition, objectives, and strategy. He argues that all these components of the project scope are compulsory to create a clear project vision. At this stage in the ERP project, the vision should provide a direction and general objective, and no details are required. ERP implementation strategy: This will be reviewed in this level to determine the impact of ERP system implementation on the enterprise. Trepper (1999) argues that the organisations executive managers must understand how ERP system implementation will impact on the organisation to ensure a smooth transition. Holland and Light (1999) suggest that the propensity of an organisation for change should influence the choice of ERP implementation project strategy. There are two main technical options to implement an ERP system: modify the ERP system package to suit an organisations requirements or the implementation of a standard package with minimum deviation from the standard settings. Companies that do not select the second option are liable to face major difficulties (Bancroft et al, 1998; Martin, 1998; Gibson et al, 1999). Hiring consultants: Due to the complexities of implementing an ERP system, most companies choose to hire consultants to help them select, configure, and implement the system. Welti (1999) argues that the success of a project depends on the capabilities of the consultants, because they have in-depth knowledge of the software. Somers and Nelson (2001) point out those consultants may be involved in different stages of the ERP project implementation. There are hundreds of companies that provide such ERP services. Since it is a critical success factor, it has to be managed and monitored very carefully. Benchmarking: Al-Mashari and Zairi (2000) argue that benchmarking works essentially at capturing both external and internal best practices related to all aspects of ERP system implementation, and enabling the transfer of knowledge across all levels of project implementation. They argue that benchmarking can play a significant role in shaping the strategic direction to be taken for change introduction using an ERP package. Tactical level At the tactical level, also termed managerial level, the medium-term planning of ERP specific organisational issues is largely concerned, where decisions are made by middle managers (Turban et al, 2000). In order to make sure that the enterprise is meeting its targets, objectives of top management are accomplished, and it is not wasting its resources, the tactical level provides middle-level managers with the information they need to monitor the performance of the organisation, control operations, and allocate resources and set policies effectively (Schultheis Sumner, 1995; Bocij et al, 2008). Client consultation: Slevin and Pinto (1987) define client consultation as the communication and consultation with, and active listening to all affected parties, mainly the client. It is essential for an organisation to keep its clients aware of its future project to avoid misconception. They also argued that the consultation with clients should occur early in the process; otherwise the chance of subsequent client acceptance will be lowered. In general, this factor has not been thoroughly discussed in the literature reviewed. Business process change (BPC): As mentioned before, there are two main options to implement ERP syst

Love Is Beautiful Essay -- essays research papers

Teenagers are so blind to love because we are young and stupid. If it weren't called a crush, it wouldn't hurt. When I believe it's not there it seems so real and overflows my body with an unexplainable feeling. No matter what I do I cannot change the unexpected. I honestly don't think anyone will be able to understand or define the meaning of love. However I love my family and friends, but I am starting to give up on loving anyone else. I hate how I'm so happy and then it`s ruined.. I hate how you make me feel so bad, however in my life I've experienced more love from you than enough pain to overcome what I already know, which is to love to the full extent. Goodbye is never goodbye until life is over. I will always be able to love someone again, just like they are able to love me. Why do I listen to others lies about love and what they know? Why don't I just love like I want to love. I exercise my mind freely and i forget what is holding it altogether. I will always be buried with feelings and emotions from past experiences whether I realize it or not. It's hard to see and understand from anyone's perspective because I am not that person and I am surely not God. I cannot relive the past, but build over faith in myself. I cannot rely on what I hear or say or even on other's ambitions. I must forgive and never forget, I believe; If I forget, what lesson was learned? Or if I were in love why would I want to forget how wonderful it was to see the person smile and why it hurts so bad now to see them smile. I hate when you wipe my tears away because I cry more knowing you see and know that the pain is there. I'm not just in love, I am deeply and desperately in love and this one time is enough. Piece by piece I take in the meaning of such a confusing feeling of emotion. Look in my eyes, which will describe the truth that my heart wants to say. It's easier to lie and walk out on love then to hurt you or myself later by just tearing up the emotions that were shared. Love is not a gift to life, it is something to take out and figure out. I love you i'd do anything to listen to what you can't say. I'd deny the truth and protect you with my life. I can't love, I already love you to a full extent. I love you as much as it seems you will allow me. Why is it that people can't rely on their own decisions and feelings of love? I don't think i will ever have tha... ...ut you I am nothing and when I am nothing, I cannot be myself because I am afraid of what I could become without you. I know you may never feel the same or you may never understand. I wish I could take back what happened or the things that changed between us, but it is not possible to change the past. I don't regret what happened, I just regret my unthoughtfulness and just not being the person I was at the beginning. I wish so many things and now I have to live with the fact that I may never get the chance again and if I did, I don't know what I'd do. I dont know what else I could say because I am so nervous. But I know that with you I wont be so scared and I don't know what else I could do to make you somehow understand. I never talk to you in person about these feelings, so there are few limited ways of me being able to speak to you. I guess I have no choice but to try and explain it as if I was talking with you. That's all I can say right now.. I wish I had more to tell you, but I spoke directly from my heart and I love you very much. You know that I am always here no matter what happens. I love you, I love you from the bottom of my heart and I always, always, always will!!

Koito Case

Koito-Pickens-Toyota Case Question 1 The Japanese corporate governance system differs vastly from the US system. Discuss corporate governance issues that may arise under the Japanese keiretsu. The corporate governance system in Japan is widely different from the US one insofar as it mostly involves a unique business model called â€Å"Keiretsu†. A Keiretsu is a form of corporate structure that groups a set of companies with interlocking board of directors and common business interests. Thus, due to its particular structure, some governance problem may arise under this Japanese Keiretsu: ) Issues from the perspectives of financiers Because the business is considered almost like an extended family, the financing may become political and the Japanese Keiretsu will almost always give favor to members of their Keiretsu. This could lead the financiers, for instance, to finance a company member of their Keiratsu they wouldn’t have finance otherwise. As far as the potential fin anciers are concerned, the main issue is the difficulty to enter and invest in the Keiretsu. Getting financial information about the Keiretsu firms could be complicated insofar as the financial and accounting statements are not disclosed.Thus, such discretion could lead to an ambiguity or a lack of understanding from an outside perspective. Actually, the keiretsu are just trying to protect themselves from what they fear the most that is to say the yakuza and the greenmailing. b) Issues from the perspectives owners As mentioned above, the keiretsu are suspicious towards the â€Å"outside† and this behavior may make foreign owners face some difficulties. Because the keiretsu system is much more in favor of inside shareholders than the outside ones, the former may find some difficulties to make the most of their shareholder rights.And this can maybe explain why the outside shareholders are often a minority in comparison with the shareholders of the keiretsu. Moreover, even if on e of the outside owners becomes the biggest one, as T. Boone Pickens did, he may not be able to use his rights as he hoped. c) Issues from the perspectives suppliers One of the main issues for external suppliers is to the relationship between OEMs and suppliers that often leads to dumping on the prices and enables the outside supplier to compete with such cheap prices.As far as the integrated suppliers are concerned, the exclusive partnership with the keiretsu they belong enables them to do business with another leading firm and to gain market shares. d) Issues from the perspectives employees On the one hand and in case of horizontal integration, the very structure of a Keiretsu can lead into a confusion in management. The management transfers are so frequent that employees do not understand for which company they really work for is. One the other, the strong stability that comes out from this system could lead to a lack of action and performance from employees. Question 2What were T. Boone Pickens’ motives when he bought the share? In the eyes of many, Mr. Pickens was only acting as a front man for Mr. Watanabe, a well-known green mailer in order to pave a way to gain power and control over the corporation. Mr. Pickens denies all these accusations of greenmailing by claiming that he bought the share to carry out a â€Å"test case† in order to evaluate the accessibility of the market. In others words, his initiative has the only aim of checking whether the United States could make, in the future, profitable investments in Japan depending of the degree of welcome of the market.Moreover, it is not implausible to think that one motive of T. Boone Pickens was the quest of profit. It should be borne in mind T. Boone Pickens targeted Koito as an undervalued investment opportunity in so far as he anticipated a Koito stock rise due to the tight link between Toyota and Koito. The good performances of Koito stock combined with the rise of the net income an d sales reinforce this idea due to the fact that the shareholder’s average annual return has impressively increased. So the pursuit of rise of the dividends could have motivated him to buy the share.As the largest shareholder of Koito Manufacturing, is he entitled to representation on the board, does Japanese law allow for that? If not what in the law could he use to get an equivalent result? With 26. 4% of stock, T. Boone Pickens should have been entitled to representation on the board of Koito insofar as the Japanese law gives him rights due to the fact that he owns more than 10% of stock. But not so in the Japanese Keiretsu point of view. He was overwhelmingly denied board access in a 1989 annual meeting. †¦It is not a custom in Japan just to say, ‘I’ve become a major shareholder so I should become director. ’†, said Takao Matsuura, president Koito Manufacturing Ltd. There are reasons to wager that his seat on the board was compromised by the fact that the company considers him as a greenmailer. Knowing that T. Boone Pickens was planning to increase his stake to 30%, he could obtain board representation by acquiring 4% more than what he expected. In fact, the Japanese law states that those with at least 34% ownership could propose special shareholder resolutions.An alternative would be to establish a new relationship between Mr. Pickens and all the members of the keiretsu based on loyalty and transparency. They would not suspect him of greenmail anymore. We can suppose that T. Boone Pickens has chosen this way insofar as he supported the adoption of a proposal prohibiting Koito from paying greenmail. Question 3 Besides board representation, T. Boone Pickens demanded higher dividend payouts. Were his demands justified? Provide quantitative evidence to back your answer. Besides board representation, T.Boone Pickens asked for higher dividend payout saying that â€Å"Boone Co’s philosophy was to put stockholder inte rests first† (page 7) and in this very case, his demand for a higher dividend can be justified. Indeed, when we look at the dividend payout ratio for the period 1982 – 1985 (Table 1), it decreases meanwhile the retained earnings was increasing (Table 2). Moreover, at the same period, the proportion of cash was also increasing. In others words, the retained earnings were not invested enough and stay as cash.Then in 1986, we noticed that the payout ratio increased up to 39% and at the same time the retained earnings and the cash goes strongly down. Finally, almost the same phenomenon is observed between 1988 and 1990. In other words, the payout ratio is not positively correlated to the retained earnings which are not invested and stay as cash. Table 1 Table 2 Is there anything in the Japanese commercial code that would allow Pickens to try to get more dividends? If yes, why doesn’t he use this? If not, based on your experience as an international investment banker, what changes would you recommend him to propose?In order to increase dividends, T. Boone Pickens had several solutions. Indeed, many researches on the conflicts of interest between majority and minority shareholders show that dividend  payout  is negatively related to ownership concentration and support the assumption that large shareholders do not appear to use dividend policy to remove excess  cash. In other words,  firms with concentrated ownership are less likely to increase dividends when profitability increases and more likely to omit dividends when investment opportunities improve. So, T. Boone Pickens could decrease the ownership concentration of Koito.There are also some more aggressive solutions to get more dividends. T. Boone Pickens could increase his shares ownership in order to increase his decision power in the General Assembly insofar as â€Å"a owner of 34% or more of the outstanding stock could propose special shareholder resolutions†. Question 4 Pi ckens accused Toyota of limiting profits earned by Koito Manufacturing. Explain how the mechanism works? This mechanism is related to the very structure of keiretsu insofar as Toyota, like most Japanese OEM, owns equity positions in its suppliers.In 1986 almost half of Koito’s output was bought by Toyota and at the same time, Toyota has built a dominant position over Koito by having a 19%-part of Koito’s ownership. Therefore, Toyota was not just one of Koito’s customers but also one of its owners. Through its powerful influence and thanks to the close and informal relationship between Toyota and its suppliers, the car manufacturer had been able to negotiate supply contracts, lower prices and then limited profits earned by Koito. Is this a self-dealing transaction? According to Steven L.Emanuel (â€Å"Corporations†, 2009), a self-dealing transaction occurs when three following conditions are met : (1) A key player (officer, director or controlling sharehol der) and the corporation are on opposite sides of a transaction, (2) The key player has helped influence the corporation’s decision to enter the transaction (3) The key player’s personal financial interests are at least potentially in conflict with the financial interests of the corporation. In the case of Koito, 3 members out of 23 are Toyota’s executives.Even if these 3 members are no longer Toyota’s executives, the Japanese notion of loyalty and the business relations between Toyota and Koito (Toyota buy 48% of Koito’s output) could imply that these three chairmen could act in favor of Toyota or at least try to satisfy the two companies. And in this way, the supplier was treated unfairly and conflicts of interests might have occurred. If Pickens gets access to financial information, how can he set out to prove his accusations? If you were an investment banker, what accounts or data would you tell him to scrutinize.If Pickens gets access to finan cial information, he could analyze the Income Statement and compare the evolution of the growth of sales and the growth of gross profit over these past years. Generally, sales and gross profit evolve in the same direction unless there is a below cost-selling. However, here we noticed for example that in 1986, as sales had grown by almost 10,2%, gross profit had grown by 7% and that in 1990, when the sales had grown by 10. 85%, gross profit had only grown up by 2. 8%. Such comparisons could be setting off alarm bells and could point out the fact that Toyota is limiting profits earned by Koito Manufacturing.On the other hand and if he can, he could also compare directly the price of goods sold to Toyota with the price of the same goods sold to minor customers such as Hino Motors. A high difference between the two prices combined with the fact that three directors of Koito are retired Toyota executives, would prove these â€Å"self dealing transactions†. Would you suggest to cha nge the charter of the organization of Koito? As investment banker, I would suggest him to analyze thoroughly the income statements and the supply contracts between Toyota and Koito in details to reinforce his accusations.As far as the charter of the organization of Koito is concerned, I would suggest to add a clause which enables a person somehow related to a strong customer or a strong supplier to be appointed as director to Koito’s board of directors. Question 5 Toyota has threatened to cut all ties with Koito Manufacturing if Pickens take over the company. How would this affect Pickens investments? If you were a minority shareholder in Koito Manufacturing, whose side would you take? Calculate the value of your shares with or without Toyota.Because Toyota is the second largest shareholder in Koito and is its principal customer, representing 48% of the total sales (Exhibit 2), we may think that cutting ties with Koito Manufacturing will lead to huge losses, at least in the first year. Let’s then calculate the value of a share with and without Toyota. In order to use the Discounted Cash Flow methodology, here are the assumptions we made : * The value of the firm is equal to the value of the discounted cash flows for the next four years plus it’s terminal value. The same growth is expected for the coming four years (this growth was calculated as the mean of the previous years growth) * Because the lack of information concerning the cost of equity we used today Koito’s beta (1. 38), a risk free rate of 3% and a Rm of 10% (return on S&P) in order to calculate an approximative WACC. Our calculations provide us with a WACC of almost 8%. With Toyota : Without Toyota : If I were a minority shareholder I would probably take Pickens’ side because he puts shareholder interests first.However, I would be careful and make sure that making stockholders’ interest first instead of company’s one will not damage the entityâ€⠄¢s wealth. Based on your assessment of the case, are large shareholders an effective solution to corporate gouvernance problem? Based on the analysis of this case, it appears that being a large shareholder is not necessarily an effective solution to the corporate governance problem. Indeed, even if T. Boone Pickens is the largest shareholder, he actually has no influence on â€Å"management issues† including those which concern the amount of dividends paid.

It/205 Week 8 Checkpoint

The U. S. Census Bureau attempted to employ a Field Data Collection Automation (FDCA) program to expedite the collection of information. The FDCA project is important to the Census Bureau for many reasons. The first reason is the reduction of costs associated with the collection of information. Going door to door with paper forms is costly. The actual forms that are used cost the government mass amounts of money to produce. These forms are then peddled door to door by people who are paid wages and completed in ink by residents.The forms then need to be submitted to a local office where another worker who also needs to be paid for their time then keys the information in manually. These numbers and data are influential in allocating federal monies to certain areas of each state and county. Additionally, senate district lines are drawn based on population. If these figures are inaccurate, due to human error, funds that are generally allotted for a certain area could be reduced. This red uction could affect many programs in the area.Road upkeep, social services and emergency response are just a few of the areas that could be impacted. Simply put, accurate data collection is needed to ensure that everyone in all parts of the country get their fair share. The failed implementation of the wireless handheld devices was plagued with issues from every level and department. On the federal level, lack of oversight posed the largest issue. The federal sector suffers from lack of oversight because in the private sector incentives are offered for the successful, timely and cost effective rollout of similar programs.Because no one was to receive bonuses or other incentives on the federal level a lack of oversight was easily achieved. The Harris Corporation was contracted to build and test the handheld devices including the software. The federal government did not effectively convey information about the census program to Harris. This poor communication made the development of t he handheld devices extremely difficult. Harris was also at fault for not providing updates on progress. The program was also plagued with technology issues caused by miscommunication.Risk management was not adequately studied to show potential issues with the handheld devices. The devices were plagued with slow speeds while transmitting information to a central office. Once the information was received other bugs and flaws within the system made the information inaccurate. The government and Harris both share the blame for the conundrum that ended up costing taxpayers billions of dollars. The risks involved with this project were easily visible from the beginning.With so much federal money on the line simple steps could have been taken to ensure that taxpayer burden would be minimized. The first step that should have been taken was to set up a committee or group of people that including congressmen, technology consultants and financial advisors. When undertaking such a large and co stly undertaking with taxpayer money at stake it is necessary to be accountable. Members of the staff on the federal and private end should have been in constant contact with each other to ensure that problems and issues were resolved.I would have set up a liaison at each end so they could effectively relay the needs of the government to Harris and Harris could relay known issues with the government. Testing and risk assessment should have been a priority and as such should have properly researched and monitored throughout the entire process. All technical specifications should have been clearly communicated between both entities and having a liaison on both ends would have facilitated proper development. I would have ensured that wireless networks were available at certain areas and that proper software was written that was bug free long before actual rollout. It/205 Week 8 Checkpoint The U. S. Census Bureau attempted to employ a Field Data Collection Automation (FDCA) program to expedite the collection of information. The FDCA project is important to the Census Bureau for many reasons. The first reason is the reduction of costs associated with the collection of information. Going door to door with paper forms is costly. The actual forms that are used cost the government mass amounts of money to produce. These forms are then peddled door to door by people who are paid wages and completed in ink by residents.The forms then need to be submitted to a local office where another worker who also needs to be paid for their time then keys the information in manually. These numbers and data are influential in allocating federal monies to certain areas of each state and county. Additionally, senate district lines are drawn based on population. If these figures are inaccurate, due to human error, funds that are generally allotted for a certain area could be reduced. This red uction could affect many programs in the area.Road upkeep, social services and emergency response are just a few of the areas that could be impacted. Simply put, accurate data collection is needed to ensure that everyone in all parts of the country get their fair share. The failed implementation of the wireless handheld devices was plagued with issues from every level and department. On the federal level, lack of oversight posed the largest issue. The federal sector suffers from lack of oversight because in the private sector incentives are offered for the successful, timely and cost effective rollout of similar programs.Because no one was to receive bonuses or other incentives on the federal level a lack of oversight was easily achieved. The Harris Corporation was contracted to build and test the handheld devices including the software. The federal government did not effectively convey information about the census program to Harris. This poor communication made the development of t he handheld devices extremely difficult. Harris was also at fault for not providing updates on progress. The program was also plagued with technology issues caused by miscommunication.Risk management was not adequately studied to show potential issues with the handheld devices. The devices were plagued with slow speeds while transmitting information to a central office. Once the information was received other bugs and flaws within the system made the information inaccurate. The government and Harris both share the blame for the conundrum that ended up costing taxpayers billions of dollars. The risks involved with this project were easily visible from the beginning.With so much federal money on the line simple steps could have been taken to ensure that taxpayer burden would be minimized. The first step that should have been taken was to set up a committee or group of people that including congressmen, technology consultants and financial advisors. When undertaking such a large and co stly undertaking with taxpayer money at stake it is necessary to be accountable. Members of the staff on the federal and private end should have been in constant contact with each other to ensure that problems and issues were resolved.I would have set up a liaison at each end so they could effectively relay the needs of the government to Harris and Harris could relay known issues with the government. Testing and risk assessment should have been a priority and as such should have properly researched and monitored throughout the entire process. All technical specifications should have been clearly communicated between both entities and having a liaison on both ends would have facilitated proper development. I would have ensured that wireless networks were available at certain areas and that proper software was written that was bug free long before actual rollout.