ICAM EAMS Enterprise Asset Management System
デベロッパー
公開チャット
製品詳細
ICAM (Integrated Computer Aided Maintenance) is from an application class referred to as ELS (Equipment Logistics Systems) or EAMS (Enterprise Asset Management System.
ICAM facilitates and documents the entire engineering activity. It provides the engineering manager with the high degree of control necessary to implement a successful scheduled maintenance program and to react quickly and decisively when unscheduled maintenance is required. Furthermore, ICAM provides the decision-makers with the complete life cycle, ownership and operational costing information. Main functional modules include.
- Maintenance Planning, Scheduling and Work Execution
- Procurement, Supplier Performance and Warranty Tracking
- Inventory Link to other Critical systems, like.: Finance/Accounting, CMS, Yard Management
ICAM is demand driven in its core design, this based on a philosophy that assumes no productive or support asset consumes resources, manpower or materials, by their simple existence. Resources are only consumed when there is WIP (Work in Process), therefore WIP becomes the source of demand. WIP itself is triggered by the operational load placed on a productive asset. As operational levels reflect commercial conditions, the business levels really determine the level of Engineering WIP. The main advantage is that the system will adjust up or down based on operational levels.
Equipment Master -
- Contains specific design information about the capacity limits for each asset type,
- Also contains data for seasonal considerations. Depending on the geographical location of a terminal, there may be some additional procedures performed only certain times of the year. This is referred to as on season , these procedures are suppressed other times of the year off season
As and example, a crane located at a terminal where winter temperatures can reach 0C will require tank heaters to keep the hydraulic oil at the correct viscosity. These tank heaters may only be used 4 months of the year, but we must have a service instruction to inspect these prior to and during cold weather. The on season period. Preparing snow removal and deicing equipment is another example.
Equipment level warranty information is also here as we may be required to do additional procedures during the warranty period, similar to break in service on a motor vehicle.
The Cycle Code also resides here, very important for scheduling as this controls the calendar week in which annual maintenance is performed. This is normally the procedure requiring most time, pegging the cycle gives un a method to assure that all annuals do not occur in the same work week, they can be staggered. Shown below is an excerpt from equipment master, the item referred to
I. PROCUREMENT This module is used to process purchase requests. It supports the entire procurement process from creation, department approval, canvassing, awarding, conversion to purchase order, PO approval hierarchies and sending the PO to the vendor via fax (Print) or email directly. The Procurement module supports the following types of purchases:
Stock Items that are physically stored in the warehouse, has existing part numbers in the catalogue and the value of the item will be stored in the inventory account. (i.e. Spare Parts)
Expense Items that have existing part numbers in the catalogue but the value will be directly expensed against the expense account. (i.e. Office Supplies)
Non-Stock - Items that do not exist in the catalogue and the value of the items will be directly expensed against the expense account. (i.e. Glue Gun)
Asset this is a purchase type used for equipments and other capital expenditures. (i.e. Furniture)
Service this is a purchase that requires labor to be performed for the business entity that made the request. (i.e. Paint the fence)
II. RECEIVING / ISSUANCE This module is used to process all the deliveries from the vendor. Received items are matched against the Purchase Order and assigned a location for reference. Issuance on the other hand is used to process all the items issued or going out of inventory. Storekeepers associate the items to a Work Order, person where it was issued to and its matching account to identify the expense account the item was issued against.
III. BUDGET This module is used to set and keep track of available CAPEX or expense budget allocations real time. Every time a PO is issued to the vendor, ICAM automatically deducts the PO amount against the budget of a specific account. Also, this module can be used to keep track of Petty Cash and other expenses that do not go thru the PO process (i.e. Utility Bills)
IV. ICAMAP This module is used for Invoice data entry, Invoice Matching and Account distribution. The Procurement and Receiving modules are performed in ICAM, it therefore logical that matching the Invoice against the PO and the Receipts should be done in ICAMAP to maintain coordinated data sourced directly from the same application.
V. VERIFYGL This module is used to check the GL information assigned by stores when issuing items from Inventory. A flag is set once a transaction has been verified to inform the system that it is ready for upload.
VI. ICAM ORACLE Interfaces This module is used to transfer or retrieve data between ICAM and Oracle Finance. The following interfaces will be developed under this module:
Accounts Payable (Invoice / Invoice Line) This interface will be used to transfer the Invoice information and Account Code distribution form ICAMAP to Oracle AP. Bank payment process and Post to GL will continue to be done in Oracle Finance.
General Ledger (Expense accounts) this interface will be used to automate the transfer of the debit and credit information for all items issued from inventory to a specific account (i.e. Repair and Maintenance)
1.1.1 User Characteristics and Objectives
The users recommended for the modules are as follows:
Requesters Tasked create purchase requisitions for each specific department except engineering spares wherein storekeepers are the people in charge of managing that inventory.
PR Approvers Tasked to review/approve the purchase requests submitted based on need.
PO Approvers Tasked to review/approve the purchase orders based on money approval following a hierarchy pre-defined by the business entity.
Buyer Tasked to negotiate with suppliers, request for quotations and selecting the best vendor available for specific requests. Depending on the business entity, a buyer may also be tasked to received items that are directly expensed and does not have to go thru the warehouse.
Storekeeper Tasked to create requisitions for engineering, receive/issue parts and selecting which account an item is issued to.
Finance Clerk Tasked to Enter the Invoice Information, Perform Invoice Matching and Account distribution.
Finance Officer Verify the GL accounts for the items issued, verify the account distribution for Accounts Payable, Perform manual execution of DTS Packages as required. Manage the Chart of Account in ICAM.
Budget Officer Keeps track of available budget allocations.
ICAM The application has built in exception handlers to manage module and connectivity errors. To manage the data, scripts that update the data are encapsulated using database transactions allowing any rollback in the event an error occurs in the middle of a transaction set. ICAM also sets the validations in its controls to make sure that it does not violate the data type and data allocation inserted in the database.
1> User Interface Validation Provides the first line of defense against invalid or incorrect data from being entered into the database. All of ICAM s user interface screens employ the use of self-validating window controls that inform the user of any possible data violations.
a. Real time Several controls validate user input right as soon as it is inserted. These validations are primarily deployed on controls that manage the filtering of row set views within the application.
b. Delayed Most validations occur just before the start of any major transaction. All control data are parsed and checked for size and character limits, allowed value range, required data, and accepted formats.
2> Transactions SQL commands are enveloped within database transactions to allow the ability to roll back any changes to databse in the event of an integrity violation.
a. Exception Handling Program and system exceptions are appropriately handled throughout the application.
b. Database Exceptions Errors returned by SQL Server are handled and displayed in readable form.
c. COM Exceptions Errors encountered within the Component Object Model interface are routed into exception handlers.
Engineering work management
ICAM facilitates and documents the entire engineering activity. It provides the engineering manager with the high degree of control necessary to implement a successful scheduled maintenance program and to react quickly and decisively when unscheduled maintenance is required. Furthermore, ICAM provides the decision-makers with the complete life cycle, ownership and operational costing information crucial in today’s competitive marketplace.
Storeroom management
Storeroom Management is a seamless extension of Engineering Work Management, meaning that required items and levels are forecast as part of the scheduling and execution of work. This results in minimal storeroom value (reduced insurance spares) while eliminating untimely stock-outs of critical items. The ability to forecast also supports bulk purchasing, item consolidation and economic order quantity programs and other cost management efforts. Unclaimed warranty receivables are eliminated by the ability to track warranty whether on receipt or installation.
Procurement management
Procurement management is a functional extension of both engineering work management and storeroom management activities. This guarantees the orderly management of requisitions and orders based upon accurately forecast requirements for both hard goods (storeroom replenishment and projects), and service (contract labor). Integrated electronic approval ensures timely processing and issuing of orders.
ファイルツリー
-
📁 ICAM EAMS Enterprise Asset Management System
インストール手順
The technical interface spec. details all actions between 2 applications. This document is used to create the actual interface, debug the interface when problems arise and to enhance/expand interface capabilities. The spec. is presented in 2 formats, graphical for top level interpretation (Visio or other), and detailed to assure correct execution (Word and/or Excel). Simple example will be used for each interface consideration.
System Wide
1. What is the basis for communications?
a. Database to database
b. Application to application
c. Combination of a. and b.
2. How do they handshake for a and b?
3. What happens when one of the database servers is down, the other running?
4. What happens when one of the application servers is down, the other running?
5. What happens if one applications causes its session to end (fatal error)?
6. What happens when both apps and DB’s are functioning normally and a network interruption occurs?
Data Sharing (DTS or SSIS for SQL Server 2005) - Batches
a smooth and efficient port terminal operations, procurement, inventory, engineering preventive and corrective maintenance, and reports analysis.
f. The training was divided into 2 category in-dept and overview
i. Overview – A general summary of a subject
ii. In-dept - A comprehensive approach of training, comprising many things and having a wide scope or full view of the ICAM-PTO module
g. Desktop and ICAM-PTO username and password
METHODOLOGY
i. Welcome to ICAM-PTO
1. Definition of ICAM-PTO system
2. Objective and Mission of ICAM-PTO system
3. Benefit of ICAM-PTO system
ii. Initial Login in ICAM-PTO
1. Changing username password and notification preferences
2. Configuring user email address
3. Selecting Users budget centers
iii. Procurement Module
1. Seamless execution of ICAM-PTO Purchase Request, Purchase Order, request for quotation, canvassing, canvassing analysis, canvassing, awarding, and managing suppliers.
2. Procurement basic, KPI a
変更と適応の手順
The technical interface spec. details all actions between 2 applications. This document is used to create the actual interface, debug the interface when problems arise and to enhance/expand interface capabilities. The spec. is presented in 2 formats, graphical for top level interpretation (Visio or other), and detailed to assure correct execution (Word and/or Excel). Simple example will be used for each interface consideration.
System Wide
1. What is the basis for communications?
a. Database to database
b. Application to application
c. Combination of a. and b.
2. How do they handshake for a and b?
3. What happens when one of the database servers is down, the other running?
4. What happens when one of the application servers is down, the other running?
5. What happens if one applications causes its session to end (fatal error)?
6. What happens when both apps and DB’s are functioning normally and a network interruption occurs?
Data Sharing (DTS or SSIS for SQL Server 2005) - Batches
1. Define segments to denote master data and session identification,
2. Methodology,
a. CSV.
b. API,
c. Shared Temp.,
d. Views,
e. Combination
3. Frequency
a. Fixed,
b. Manual,
c. Combination
4. Audit procedures,
5. Recovery and/or rollback
Events; Cumulative and Real-Time
1. Define all cumulative events: counts, hour meters, minor trips and/all warnings,
2. Define all real-time events and intended action for each event, additional rules.
An example of item 2 would some event that could trigger an emergency WO, to do this fault severity levels must also be defined. An example of a rule would be a case where a WO already exits for a specific problem on a specific equipment (invoke Verify to prevent duplicates.
The is a lot more detail for many items:
1. What is the name of each trigger or SP being invoked,
2. What type of transaction; Insert or Update,
3. What tables and columns are affected.