电信项目实施文件05option2phase.doc

Section 5: Option 2 Phase 1 Implementation (Logistics)5.1 SummaryOracle has recognized that HKT needs to focus on Y2000 compliance for its Logistics Information System and thus stay operational beyond 1999. In addition to Oracle s proposed Option1 Phase 1 Oracle has evaluated the functionality of HKTs internal Legacy Satellite Systems and their fit to the Oracle proposed products. Oracle proposes HKT to replace most of the internal Legacy Satellite Systems through use of standard Oracle Applications. This approach not only builds a foundation for further improvements using Oracles products and services but also gives a new dimension of flexibility on a short term basis securing meeting the critical Y2000 deadline and at the same time providing the ability to incrementally improve HKTs business operations.This approach is going to be less complex from both an implementation standpoint as well as from a user acceptance standpoint as in long term there will be less data redundancy and less effort in maintaining the satellite system. It is Oracles opinion that Option2 would give the safest way to meet short term goals and also satisfy long term strategic objectives with a cost effective program.Option 2 Phase 1 of the Business Support System will be positioned as the core element of Hongkong Telecoms integrated operational and management information system which will allow Logistics operational analysis and forecasting at both the management and operational level. The core of the Option 2 Phase 1 solution is the Oracle Logistics and Distribution Packages. These application software packages are “off the shelf” applications which support the business activities of Order Management, Purchasing Supply Chain Planning and Distribution. These applications have been built using Oracle Developer/2000 on Oracle RDBMS.Surrounding this core package will be a minimum set of custom extensions to support agreed upon functionality gaps not supported by the applications. Initially these gaps will be carefully reviewed for Option 2 Phase 1 impact with a desire to minimize risk and realize a faster implementation. Custom extensions will be developed using Oracle Developer/2000 for consistency in the user interface. 5.2 ScopeA well-defined scope establishes the parameters and outcomes of the project. This section presents our current understanding of what Hongkong Telecom requires from Oracle to address the stated system needs. Hongkong Telecoms requirements serve as the foundation for this proposal. The scope of this proposal is based on the Request for Proposal information , interviews with the key users from the main business functions, the document “Requested Scope And Strategy For Quotation From Suppliers” dated 3 October 1997, and is outlined in the following sections.Please refer to Appendix B Compliance Table - Logistics Requirements. Appendix B1 provides the Statement of Compliance and Appendix B2 provides Option 2, Phase 1 Inclusion List.Appendix C of this proposal lists all Hongkong Telecom Business Requirements for Financials. Appendix C.1 is a statement of compliance for all financials business requirements to be included in Option 1 and Option 2. In this document, all financials requirements that are NOT underlined (unless specified) will be PMO requirements and will be included in Option 1. Those that are underlined and in italic form will be FMO requirements and will be included in Option 2. Those that are underlined but not in italic form will be out of the scope of both Option 1 and Option 2. For details about what will NOT be included in Option 1 Phase 2, please refer to Appendix C.2 Option 1 Phase 2 Exclusion List.5.2.1 Included in Scope Oracle Applications Modules- Section 5.3 Internal satellite Systems- Section 5.4 Extensions - Section 5.5 Interfaces- Section 5.6 Reports- Section 5.7 Training- Section 5.9 Project Milestones- Section 5.10 Project Organization- Section 5.11 Project Gantt Chart & Critical Path- Section 5.12 Project Teams (Oracle and HKT) - Section 5.13Resource Estimate Key Deliverables- Section 14.25.2.2 Out of Scope AreasThe scope of work in this implementation proposal does not include any tasks or activities related to the following : Data Conversion This task involves extracting the data from the in-house system and loading it into the Oracle Applications. This task will not be performed by Oracle Consulting Service (OCS). A flat file format will be supplied to HKT by the OCS project team and it will be the responsibility of HKT to supply the conversion data in the ASCII file format provided and load this into the Oracle Application. It is the responsibility of HKT to ensure the validity and accuracy of this data. Interfaces: The provision of any interfaces into or out of the Oracle Financials that has not been included in the Interfaces Table outlined in section 5.6 of this proposal will be out of the scope of the project. Any time spent assisting HKT on the design, build or testing of these additional interfaces will be subject to change control. End User Training: All end user training will be conducted by Hongkong Telecom. Business Process Reengineering/Redesign: The assumption that we make in this proposal is that the business processes will not differ substantially from what was provided in the tender document provided HKT. The team members will perform analysis and understand these processes and map it to the proposed package. They will not undertake to recommend changes or undertake to change these processes. However in the course of mapping these to the package, if a modification to the process is necessary and has a positive result, the team may recommend a change. This will have to be accepted by HKT before any implementation. Again any changes proposed will have to be handled as per the Change Control Procedure. Additional Custom Extensions: Based on our understanding of the tender a number of custom extensions have been identified (please see section 5.5 of this proposal). Any additional custom extensions will be handled as per the Change Control Procedure. Hardware selection: Oracle proposal for the implementation of Oracle Financials does not cover the selection of a hardware vendor. Information can be provided on the certified platforms but any selection of vendors is outside of this scope. Network or Benchmark testing: The only testing that Oracle will undertake is the unit testing of custom extension. OCS may perform ad-hoc conference room pilot testing of system functionality but this is at the discretion of the OCS project manager.5.3 ModulesThe Oracle Applications modules to be implemented in Option 2 Phase 1 are : Oracle Alert Oracle Inventory Oracle Bill of Materials Oracle Service Oracle Quality Oracle MPS/MRP Oracle Purchasing Oracle Order Entry Oracle Work in Process Oracle General Ledger (Shell) Oracle Payables.5.4 Internal Satellite SystemsBased on recent information from HKT, IS Strategies & Architectures Proposal Version 0.1 dated 6 May 1997 (Confidential),Oracle has investigated the requirements specified listed on pages 1 through 33 , as well as on Specifications on Internal Satellite Systems handed out at meeting held on 6 October 1997. Based on this new information Oracle has concluded that most of the functionality provided by these Internal Satellite Systems can be fulfilled through use of the standard functionality in the proposed Oracle Products. This conclusion is valid for the following Satellite Systems; Mobile Sales and Administration System - MSAS Serialised Stock Tracking System Delivery Order Transmission System Stores Location System Stock Check System Rework Phone System Scrap Removal Control System Equipment Register System Supplementary Materials Control System Non - code Item Inventory Control System Quality Inspection Management System Receipt and Inspection System Vendor Information System. Contract Information System Transaction Library Utilities System Rent & Rates System Manual Check printing System AP Archive Data System Currency Management System. In addition, it has been indicated to Oracle that the provision of a Phonecard system for Hongkong Telecom can produce considerable financial benefits. At the time of writing this proposal, Oracle has not received any separate documented requirements for that system but has been assured that the PMO Specification, plus the recent additional FMO requirements, will cater for the new Phonecard system. On that basis the Phonecard system is included in the scope.For the remaining Systems Oracle recommends that HKT takes the following course of action in order to reduce complexity and to reduce scope of the project for the next 12 - 18 months. This is important for HKT to meet Y2000 compliance in time. Oracle also believes that the standalone Warranty Repair system may also remain separate at this stage as no interface is required and there are not perceived immediate benefits.The current Phonecard system (page 15, “IS Strategies & Architecture Proposal, Logistics Information System”) is for a type of Phonecard which is being phased out and that standalone system will not be replaced.The Back to Back System, MRI system and Petty Cash system will be kept as Satellite System until further investigation and the necessary interface will be are built during the implementation of the project. The Power-base System information Oracle has received and we believe that this System should continue be a stand alone System.However if this conclusion is wrong and there is adequate information that changes this assessment Oracle is willing to discuss any such change using procedures described under Scope Change Control Process And Procedures.5.5 ExtensionsIt is recommended that Hongkong Telecom should implement each of the Oracle application modules with minimal changes and/or modifications for Option 2, Phase 1. We have based this proposal on the assumption that the project team will make no changes to our applications modules except as delineated belowListed below are the known custom extension requirements which are included in this proposal.5.5.1 Vendor Lead Time ManagementHongkong Telecom has the requirement, which will be provided by a custom extension, to present the following functionality in Option 2 Phase 1: Identification of the Lead Times per Item for each Vendor, and to have the Vendor ranked in order of preference. Automatic creation of requisitions when the available quantities in Inventory are not sufficient to satisfy demand. Automatic creation of requisitions based upon best match for the item promise date (on the order) when vendor lead time is taken into account. Automatic user notification if no Vendor can provide delivery of specific items to meet the Promise Date on the Order Lines.5.5.2 Total Landed Cost AssignmentHongkong Telecom has the requirement, which will be provided by a custom extension, to present the following functionality in Option 2 Phase 1: Identification of algorithms, or percentages, that assign the values of Freight, Duty and Insurance to the item specific cost at time of receipt. Identification of these percentages for each Purchase Order Line. Providing defaults of these percentages based upon the item category for each Purchase Order Line. Ensuring that the percentages for all Purchase Order Lines, on one Purchase Order, exactly sum to 100%. The ability to record the Freight, Duty and Insurance costs associated with each inventory receipt and add these extra costs to the receipt cost of the particular item.5.5.3 Order EntryAt Order Entry Screen, it is required to give the user a sorting option in viewing the existing lots 9drums) in descending order of variance percentage (requested length vs available length).5.5.4 PurchasingUpon rejection of goods after receipt, give user a option to auto generate a debit memo. Oracle Alert should hold the payment for all the invoices with the matching PO item shipment line.5.5.5 Cable Stock Management SystemBest Fit Pick Process (Batch) - Start searching for all the shortest -length cables to meet the best fit (may be with acceptable tolerance %)5.5.6 Accounts PayablesRequirementsModification DescriptionAccounts Payables1.3.2.2Due DateThe system must be capable of selecting invoices for payment on the basis of a range of dates and the user may then pay all invoices selected or edit the selected invoices prior to initiating the payment process.You can only enter a due date in the payment selection, not a due date range.Provide another payment selection program, or change the existing program to allow enter due date range.1.4.1.2Alternate PayeeIn a number of instances suppliers have directed payment to be made to a third party at an address different from that of the supplier. The system must be capable of maintaining the necessary records to support an alternate payee. The system shall be able to settle all invoices of a vendor, including all redirected invoices from other vendors using the alternate payee function, in one single cheque in a payment cycle.You can store alternative payee name or use one of the contact person as alternative payee.Create a flag to indicate whether alternative payee will be used or not by descriptive flexfieldChange of the payment program to select alternative payee based on the flag.Another way is to create the alternative payee as a normal vendor in the systemUse descriptive flexfields to store the vendor code of the alternative payee.Change the payment program to use the alternative payee vendor details.1.5.3.2Invoice TrackingWith the functionality outlined in 1.5.3.1, the system must be capable of tracking the progress of the invoice by location and processing stage. This information should be accessible to users enquiring of the progress of the invoice.System should be able to record the name and location of the action officer who approve the invoice or perform invoice matching to PO.Descriptive Flexfields can be created to store the required informationCreate a new invoice inquiry function which allow user to enter criteria in the descriptive flexfields1.2.4.9Bank AccountsThe system shall be able to automatically assign the appropriate bank account for paying the invoices based on account code, amount and currency.The system should be able to perform the following :1. based on the account code to determine the type of expenses : CAPEX or OPEX2. There are specific bank accounts assigned for CAPEX and OPEX expenses respectively.3. For OPEX expenses, if the amount is less than a predefined amount (e.g. 1M), a particular bank account will be used. Otherwise, another bank account will be used.Program modifications :1. In bank account maintenance, add fields to specify whether the bank account will be used for OPEX and CAPEX and for what amount range.2. In invoice, store the information which can be used to determine the type of expenses (note that the account code structure may be changed so that it may be not able to use the account code to determine the type of expenses in future)3. In payment batch creation, user still need to specify they want to pay OPEX or CAPEX expenses and amount range by specifying the bank account4. Change the invoice selection program to provide the intelligent to base on the flag stored in the invoice to determine the type of expenses and amount range. It then select only those invoices for payment.5.5.4 Internal Satellite Systems FunctionalityBased upon the information Oracle has on the Internal Satellite systems functionality Oracle has identified minor extensions and or workarounds to be applied for replacing the following two Satellite Systems by using Oracle Standard Products, the Mobile Sales and Administration System-MSAS and the Deliver Order Transmission System. During the Definition phase of the implementation Project the detailed requirements will be defined and agreed upon. 5.6 InterfacesThe complex mix of existing legacy Satellite Systems ,25 systems recognized as internal and another 12 systems recognized as external to the logistics system , new custom systems, and non-Oracle systems make interface development a critical part of the project.However through the replacement of 20 internal satellite systems by Oracle Applications standard function and features, the effort of developing interfaces has become less critical for the project implementation and gives HKT an important benefit in embedding some of the standalone systems as integrated parts of the Logistics system. Thus avoiding redundant data capture and maintenance effort of the Satellite SystemThe Oracle project manager together with the Hongkong Telecom project manager will manage the remaining interface development process using Oracles interface development procedures. 5.6.1 System InterfacesOracle will develop twenty-six (26) interfaces between 2 internal and 12 external Satellite Systems and the Oracle Applications. All interfaces will be file-to-file interfaces, not program-to-program interfaces. Data will be exchanged via a flat ASCII file. For outbound interfaces from Oracle Applications, Hongkong Telecom will specify the format of the file to be produced. The information to be provided must be available to the Oracle Applications. Oracle will create a file on the server where the Oracle Applications exist. These files will exist in a temporary holding area where Hongkong Telecom can pick up the file and transfer the data to other external systems if necessary. For interfaces that are inbound to the Oracle Applications, Oracle will specify the format in which the information is to be provided. Hongkong Telecom needs to provide the file to the server where the Oracle Applications exist. This format will be consistent with the application program interfaces (APIs) that are available for Oracle Applications.A list of interfaces by Oracle Application Module is provided below, along with an indication of the complexity of each interface. The cost and time to complete the interface work is based on the number of interfaces and the complexities. Interfaces may be added or removed during the Operations Analysis phase without any impact to cost or time to implement, provided the total number of interfaces and the complexity mix does not change. Any changes to the number or complexity mix of interfaces is outside the scope of the this proposal.Interface PointInbound or OutboundOrigin and Destination SystemsComplexityAccount Code combinations from D&B General LedgerInboundD&B General Ledger to Oracle General LedgerMediumAccount Journals from the GL InterfaceOutboundOracle General Ledger to.D&B General Ledger.Very HighShipment Details for Invoice creation within D&B Accounts ReceivableOutboundOracle Order Entry to D&B Accounts ReceivableHighReturn Material Authorization information for Credit Memo creation within D&B Accounts receivableOutboundOracle Order Entry to D&B Accounts ReceivableMediumCustomer Interface (including Credit Ratings)InboundD&B Accounts Receivable to Oracle Order EntryHighInvoice Information (Types, Terms etc.)InboundD&B Accounts Receivable to Oracle Order EntryMediumTransaction StoresInboundTransaction Information from Oracle InventoryMediumBTBS project InformationInboundIssue,receipt and return Information from Oracle InventoryMediumAvailable Item QuantityOutboundOracle Inventory to Complex DragonMediumAvailable Quantities