ACCA考试P1-P3模拟题及解析20

　　2014年12月ACCA备考已经开始了，以下是高顿网校小编为学员整理的：ACCA P1-P3模拟题及解析，供学员参考。
 

　　Flexipipe is a successful company supplying flexible pipes to a wide range of industries. Its success is based on a very innovative production process which allows the company to produce relatively small batches of flexible pipes at very competitive prices. This has given Flexipipe a significant competitive edge over most of its competitors whose batch set-up costs are higher and whose lead times are longer. Flexipipe’s innovative process is partly automated and partly reliant on experienced managers and supervisors on the factory floor. These managers efficiently schedule jobs from different customers to achieve economies of scale and throughput times that profitably deliver high quality products and service to Flexipipe’s customers.

　　A year ago, the Chief Executive Officer (CEO) at Flexipipe decided that he wanted to extend the automated part of the production process by purchasing a software package that promised even further benefits, including the automation of some of the decision-making tasks currently undertaken by the factory managers and supervisors. He had seen this package at a software exhibition and was so impressed that he placed an order immediately. He stated that the package was ‘ahead of its time, and I have seen nothing else like it on the market’.

　　This was the first time that the company had bought a software package for something that was not to be used in a standard application, such as payroll or accounts. Most other software applications in the company, such as the automated part of the current production process, have been developed in-house by a small programming team. The CEO felt that there was, on this occasion, insufficient time and money to develop a bespoke in-house solution. He accepted that there was no formal process for software package procurement ‘but perhaps we can put one in place as this project progresses’.

　　This relaxed approach to procurement is not unusual at Flexipipe, where many of the purchasing decisions are taken unilaterally by senior managers. There is a small procurement section with two full-time administrators, but they only become involved once purchasing decisions have been made. It is felt that they are not technically proficient enough to get involved earlier in the purchasing lifecycle and, in any case, they are already very busy with purchase order administration and accounts payable. This approach to procurement has caused problems in the past. For example, the company had problems when a key supplier of raw materials unexpectedly went out of business. This caused short-term production problems, although the CEO has now found an acceptable alternative supplier.

　　The automation project

　　On returning to the company from the exhibition, the CEO commissioned a business analyst to investigate the current production process system so that the transition from the current system to the new software package solution could be properly planned. The business analyst found that some of the decisions made in the current production process were difficult to define and it was often hard for managers to explain how they had taken effective action. They tended to use their experience, memory and judgement and were still innovating in their control of the process. One commented that ‘what we do today, we might not do tomorrow; requirements are constantly evolving’.

　　When the software package was delivered there were immediate difficulties in technically migrating some of the data from the current automated part of the production process software to the software package solution. However, after some difficulties, it was possible to hold trials with experienced users. The CEO was confident that these users did not need training and would be ‘able to learn the software as they went along’. However, in reality, they found the software very difficult to use and they reported that certain key functions were missing. One of the supervisors commented that ‘the monitoring process variance facility is missing completely. Yet we had this in the old automated system’. Despite these reservations, the software package solution was implemented, but results were disappointing.

　　Overall, it was impossible to replicate the success of the old production process and early results showed that costs had increased and lead times had become longer.

　　After struggling with the system for a few months, support from the software supplier began to become erratic. Eventually, the supplier notified Flexipipe that it had gone into administration and that it was withdrawing support for its product. Fortunately, Flexipipe were able to revert to the original production process software, but the ill-fated package selection exercise had cost it over $3m in costs and lost profits. The CEO commissioned a post-project review which showed that the supplier, prior to the purchase of the software package, had been very highly geared and had very poor liquidity. Also, contrary to the statement of the CEO, the post-project review team reported that there were at least three other packages currently available in the market that could have potentially fulfilled the requirements of the company. The CEO now accepts that using a software package to automate the production process was an inappropriate approach and that a bespoke in-house solution should have been commissioned.
 

　　(a) Critically evaluate the decision made by the CEO to use a software package approach to automating the production process at Flexipipe, and explain why this approach was unlikely to succeed. (12 marks)

　　(b) The CEO recommends that the company now adopts a formal process for procuring, evaluating and implementing software packages which they can use in the future when a software package approach appears to be more appropriate.

　　Analyse how a formal process for software package procurement, evaluation and implementation would have addressed the problems experienced at Flexipipe in the production process project. (13 marks)

　　(25 marks)
 

　　(a) A critical evaluation of using the software package approach at Flexipipe could be structured around three factors. The first concerns the wisdom of using a package solution for a process where the company enjoys a competitive edge over its competitors. The second factor focuses on the difficulties of selecting an appropriate package in an environment where requirements are difficult to define and are still subject to change. The final factor revolves around the problem of successfully procuring a software package in an organisation which lacks both experience and a process for selecting and procuring a nonstandard software application. Each of these factors is now considered in turn. Other appropriate factors and relevant approaches will be given credit.

　　Competitive edge

　　It is generally accepted that software package solutions cannot provide organisations with a competitive edge. By definition such packages are available to all companies in a sector or market and so any commercial advantages offered by the package are available to all organisations competing in that market.

　　It is recognised that the control of the production process at Flexipipe was very innovative. It provided the company with significant competitive edge over their competitors. For this reason, it seemed unlikely from the start that Flexipipe would find a package that fulfilled its exact requirements and that any selected package would constrain the production process. Indeed,this is what happened, with the new system unable to replicate the flexibility and efficiency of the existing one.

　　Initially, the company would have been advised to consider the location of the process on the Harmon process/strategy grid.

　　The process is strategically important and relatively complex. Software package solutions should primarily be considered for reasonably straightforward commodity processes which have low strategic importance to the company, such as payroll and accounts. Thus, in the context of Flexipipe, a bespoke software solution would, from the outset, appear to have been more appropriate.

　　Complexity and nature of requirements

　　It was recognised from the start that it was relatively difficult to specify all the requirements of the production process in advance because many decisions were intuitively taken by experienced managers and supervisors on the factory floor. It was often difficult for them to explain why they had taken certain effective decisions. It is very risky to select a software package against incomplete or unarticulated requirements. If significant requirements are missed or misunderstood then it is difficult to address the problems this might cause.

　　There are at least three potential approaches to addressing the problem of the software failing to fulfil requirements, but each of these has disadvantages. The first approach is to ask the software vendor to integrate these requirements into the next release of the package. However, even if the software vendor agrees, it may be a costly solution as well as allowing such innovations to become available to all users of the package. The second approach is to ask the software vendor to build a tailored version of the application to fulfil specific requirements. This is likely to be expensive (so reducing the cost advantages of buying a package) and cause long-term maintenance problems and costs as the tailored version has to be integrated with new releases of the standard software package. The final approach is to seek a manual work-around for the missing requirements. However, this may also be costly as well as reducing the business benefits which should have been obtained.

　　Whichever approach is taken, it is likely to either reduce the benefits or increase the costs of adopting a software package solution.

　　It was also recognised that requirements are likely to change in the long term. There is no guarantee that the software vendor will develop the package to fit newly emerging requirements and so the issues of tailoring and work-around will again have to be considered. Most package selection takes place against current requirements and so this approach is well-suited to circumstances where requirements rarely change and, if they do, they are specified by legislative bodies and the software vendors must make the changes to keep their product compliant. Payroll and integrated accounts applications are typical of this. Applications that are subject to long-term changes (such as the production process at Flexipipe) and do not require legislative compliance, are less appropriate to this approach.

　　Absence of mature procurement process and management expertise

　　It was recognised from the outset that Flexipipe did not have an established process for software package selection and implementation. This was a very risky project in which to try and establish a process and select an appropriate package. Lack of procurement expertise in general has been a problem in the past for the company when a key supplier of raw materials for the pipes went out of business. This caused short-term production problems, although an alternative supplier had eventually been found. However, procurement still only employs two people full-time and they are relatively junior and overworked.

　　The company appears to have a very immature procurement process.

　　The long-term commitment to an external supplier is very problematic in software supply, where moving formerly in-house applications to a new supplier can be technically difficult, expensive and disruptive. In general, there are significant risks associated with the long-term viability of software suppliers and the maintenance of software applications that are critical to the company. Companies go out of business, as in the case study scenario, and companies are sold. It is feasible that a software supplier might be bought by a competitor of Flexipipe, threatening long-term supply. These problems are largely absent in bespoke development, particularly if this development is undertaken in-house. The software program code belongs to the company (not the supplier) and its long-term development is under its control.
 

　　(b) In the context of the Flexipipe project, here are some of the issues that could have been addressed by a formal software package evaluation process. It is important that candidates identify elements of the process relevant to the Flexipipe scenario.

　　A generic evaluation process is insufficient.

　　The business case for all software procurement projects should be assessed to see if a package is an appropriate solution.

　　In some instances a bespoke IT development may be better suited. As mentioned in the answer to the first part of this question, the Harmon grid considers process complexity and strategic importance and it could have been used as a guide to assessing the appropriateness of the software package solution approach. If it had been used at Flexipipe then it seems likely that the software package approach would have been abandoned at an early stage of the project.

　　The requirements must be carefully and comprehensively specified before embarking on a procurement exercise.

　　Difficulties with specifying requirements may again lead to a re-consideration of the bespoke approach. In the case study scenario,mention is made of the system failing to fulfil a number of functional requirements, such as monitoring process variance. The inference is that these requirements were either not specified or were incorrectly specified in advance and so were not part of the package assessment. Similarly, problems with ‘usability’ may be due to the failure of defining specific usability requirements in advance and so these were not considered when the package was evaluated.

　　The tendering method has to be made more formal and competitive. A post-project review has shown that there were at least three other packages which should have been considered in the evaluation process. A more formal process would have had a mechanism for finding these potential suppliers. The openness of the tendering process would also have been assisted by advertising in trade magazines and internet tendering sites, which may have also brought forward other potential suppliers.

　　This is an important step because it allows a transparency in the process, and avoids selecting a supplier purely on the recommendation of one internal employee: as in the case of Flexipipe. It would have avoided the situation of a package being selected solely on the basis of a visit to an exhibition.

　　Suppliers who submit tenders must be evaluated against criteria agreed in advance. Buying a software package leads to a long-term relationship between the supplier and the customer, so the latter must be comfortable with the supplier’s credentials. In the context of Flexipipe this would involve setting standard measures and minimum values for liquidity, gearing and profitability. There also has to be some way of off-setting the supplier’s suitability with the suitability of the product. That is, how a package with limited functionality from a well-established, financially sound supplier is evaluated against a more functional, usable package from a newly established company with high financial gearing and low turnover. The balance between such factors has to be established in advance, often using a high-level weighted matrix. In the context of the scenario, appropriate financial checks should have identified the high gearing and poor liquidity of the supplier that eventually led to its collapse.

　　A proper process also needs to be in place to evaluate the potential solution against the specified requirements. It is important to establish the ‘fit’ between the requirements and the potential solution and to use this ‘fit’ in the final selection.

　　It has been stated elsewhere that it is unlikely that a package solution will exactly fulfil all requirements. However, if the ‘fit’is known and understood in advance then negotiation with users may lead to them dropping, modifying or finding workaround for these gaps. Perhaps some of the functional shortcomings identified by users might have been tolerated, if they had been known and understood in advance.

　　Finally, a planned implementation is an important part of the process. Perhaps the lack of usability of the software was down to the absence of training and the belief that users could ‘to pick up the software as they go along’. This is a risky approach, even in circumstances even with experienced users and in a situation where the software product is a good fit with their requirements.
 

　　高顿网校小编寄语：生活充满了选择，而生活的态度就是一切。

 　　　　　　

　　扫一扫微信，*9时间获取2014年ACCA考试报名时间和考试时间提醒

　　高顿网校特别提醒：已经报名2014年ACCA考试的考生可按照复习计划有效进行！另外，高顿网校2014年ACCA考试辅导高清课程已经开通，通过针对性地讲解、训练、答疑、模考，对学习过程进行全程跟踪、分析、指导，可以帮助考生全面提升备考效果。
　　
　　报考指南：2014年ACCA考试备考指南
　　免费题库：2014年ACCA考试免费题库
　　考前冲刺：ACCA备考秘籍
　　高清网课：ACCA考试网络课程