PBL Session 2 Draftly (Pujaan Malaya - AC2206B/AIS630)

(Event 2: Senior Executive’s concern)

1)    I agree with this point of view because the costs, the time to implement and resulting benefits will clearly see in form of written report rather than oral presentation.  Besides that, the written report provides a permanent record of the messages that have been sent and can be saved for later study. Since they are permanent, written forms of communication also enable recipients to take more time in reviewing the message and providing appropriate feedback.
For these reasons, written forms of reports are often considered more appropriate for complex business messages that include important facts and figures. Other benefits commonly associated with good writing skills include increased customer/client satisfaction and enhanced image in the community and industry.

2)    There are many options that Pahang Electronics Sdn Bhd may to consider when the old system should be replaced. Among of the options are:

                      i.        Internal Support for Software Purchase

Ensuring people know what is going to be involved, and are fully supportive of the effort to purchase and implement software is critical. I do mean critical in the sense that if it is not in place, you will likely die. Many executives believe purchasing and implementing software is just a touch more complicated than buying and installing a shrink-wrap piece of software on their home computer. They need to understand that selection will require a rigorous process involving a number of people over a number of weeks or months and implementation will probably cost more than purchase.

                     ii.        Resource Impacts

We identified roles and responsibilities for the implementation. We then identified the skills required to fill those roles. Examples, the skills narrowed the candidates down to a group of eight or ten mid to senior managers.

                    iii.        Go Looking

Assuming your organization is convinced it will commit to the effort required to implement a new package, the next decision to be made is “Do we go looking at solutions first and then work out requirements?” and “Do we work out requirements before we go looking for solutions?.

For example, if our organization has no knowledge or experience in web services, and that is where we are going, we probably need to bring some people up to speed. The vendors are a way to do that, but keep in mind they will show us what their software can do. They won’t show us what web services can do.

 A better solution is to bring in an independent expert. Run a one day workshop with one or more experts to bring people up to speed on the area. Find out what is potentially applicable to our business.

                   iv.        Macro Requirements

Macro requirements are not limited to functionality. They might relate to operating systems, cost, time to implement, compatibility with other software, local support, installations in our industry, and access to source code, vendor size or any other aspect of the software. Use a workshop with all key stakeholders to develop a list.

Do a scan of the market and identify all potential packages. Review each package and cull those that do not meet our macro requirements. In many cases, we will not even have to speak with the organization. If ability to run on UNIX is a macro requirement, you can quickly establish from the web if the package will run on UNIX.

                    v.        Demonstration Agenda

It is now time to look at the software. Make sure we drive the agenda of the demo. Take the time to put together an agenda that covers what we want to see. If each vendor follows the same agenda, it will make it easier to compare different vendors.

Contact each vendor and ask them to provide a demonstration. It can be at our premises or their premises depending on the product. If we do it at our site, there are potentially issues of connectivity, performance, and configuration. On the other hand, a vendor site is going to run like clockwork which may not be indicative of how easily the software will be to run in our environment.

                   vi.        Post Macro Evaluation Cull

After the demonstrations, gather the attendees and determine which the best fit is, and which we want to proceed with. We should have a goal of anywhere from two to four packages at this stage. If they are very close, we might decide to proceed with two or three and keep the others in the running should one of the selected ones fail to deliver in the next phase.

                  vii.        Micro Functional Evaluation

It is likely that a number of business people will be involved in different functional evaluations. For a financial system, our Accounts Receivable people may have a list of functions to check, and our Financial Accounting people another list. Similarly, the vendor may use different people for demonstrating different functions.

                 viii.        The Time Between

All this is going to take time to arrange, and carry out. There are other activities that can be undertaken in parallel. For example, we can arrange over this period. Review of a standard contract by our legal people and Vendor to provide indicative costing including all normal charges.

                   ix.        Final Decision

All the factors discovered to date start to come together into the almost final decision.

We still need to:

• Check reference sites

• Negotiate the price

• Iron out any contractual issues

• Review implementation effort and cost

3)    The procurements of software package including hardware involves 5 basic steps which are

                      i.        Evaluate the information systems requirements

Analyze the requirements of your information system by identifying its key features. Before we start building something we need to know what it is that we have to deliver, and that means developing a proper requirements specification.  One important thing to consider here is “are we buying the intellectual property rights to custom-built software or changes to package software”.  Also consider our requirements for delivery dates.
We may have business analysts who prepare requirements documentation and a development team who prepare technical specifications documents.

                    ii.        Identify Potential Vendors

Once we know what the business requirements are, we can start contacting suppliers to find out if they are able to provide us with suitable services.  This stage of the procurement lifecycle could simply involve contacting the company we normally use and asking them if they want to take on the job. 

It takes a great deal of time and effort to properly evaluate the potential fit of software package and vendor to our needs and it also takes considerable effort and expenses on the part of the vendor.

                   iii.        Negotiation and award

Even when we have selected a supplier it is important that detailed negotiations are undertaken. This is not just about price. Think in terms of Total Cost of Ownership. A cheap product is not so cheap if the carriage costs are huge or if the maintenance contract is onerous.

Consider carefully the process by which the goods or services will be ordered and approved; how they will be delivered and returned if necessary; how the invoice process will work and on what terms payment will be made. Considering the whole Purchase to Pay process (P2P) at the outset can reduce costs and risk significantly.

                   iv.        Select and Purchase the Software Package

After selecting a vendor, it is necessary to agree to a contract that protects both parties. Once the contract has been signed, the vendor would install the package by considering the built-in functionality of the package, the degree of uniqueness of the company’s needs and the willingness of the organization and vendor to compromise on the issue of the closeness of the fit between the organization’s needs and the software features.

                    v.        Install the software Package

The systems will still have to be tested, users trained and a conversion strategy to move from the old system to the new one. One major difference between implementing packaged software and a custom-built one is that the construction. Nevertheless, it still may be necessary to create software to integrate the new application with organization’s existing legacy system.

4)     

Advantages	Disadvantages
·         Lower cost. Development costs are spread. ·         Faster implementation. Programs are already written. ·         Personnel savings. Fever in house programmer/analysts required. ·         Reliability. Can verify with other customers. ·         Documentation. Available for inspection. ·         Training. Provided by the vendor.	·         Incompatibility. May not be compatible with existing procedures or other installed software. ·         Maintainability. Customization may lead to difficulties in updating programs. ·         Vendor stability. Vendor may abandon product or go out of business.