Integrating All Information Assets Part Three: What Constitutes Integration?

So, whether the need for integration arises from the proliferation of business applications within your own enterprise, the results of mergers and acquisitions, or from the demands of e-business, integration emerges as a significant challenge in responding to the demands of business today. What then constitutes integration and how to you go about meeting these challenges?

Oddly enough, just as there are three predominant reasons why integration is an issue, there are three aspects of integration:

1. The most basic requirement of integration is at the data level.

2. The second aspect is perhaps the most complicated and problematic level since it is the one that is buried the most deeply into the application. This second aspect involves the actual application logic itself.

3. The third level is one of consistency and universality of access and visualization.

This is Part Three of four-part excerpt from the book ERP Optimization (Subtitle: Using Your Existing System to Support Profitable E-Business Initiatives) and is available through www.crcpress.com.

Parts One and Two presented the reasons integration is an issue.

Part Three covers what constitutes integration.

Part Four discusses what approach you should take.

Data Level

At the data level, there is master data, transactional data, and data that might be viewed as somewhere in between. This "in-between" data is that which is typically stored with the master data but becomes dynamic as the result of transactions—inventory and account balances, allocations, and reservations.

With the proliferation of applications comes proliferation of master data. Within a single company or division, having multiple copies of master data such as customer, supplier or inventory data, in itself, is not the problem. The fact that the information resident in these multiple copies may be different is the problem. In a rather simplistic example, an order entry application, whether it is a back-office application or a web-enabled electronic storefront, must have access to customer and credit information and inventory availability. Supporting master data can potentially reside in an order entry system, an inventory system and an accounts receivable system. Theoretically ERP took care of this problem with the introduction of a single integrated database.

Theoretically yes, but universally? No. The comprehensiveness of ERP implementations in general has been overestimated. Many companies that have purchased ERP systems, are still running a hybrid mix and as the push to web-enable legacy systems increases, this condition will grow. The need to share common data between applications will grow along with it.

In a multi-organizational environment, particularly one that has grown and developed either by acquisition, or with a planned level of autonomy, the goal is typically to gain access or a view of data across multiple sites and applications. In our simplistic example, the inventory availability may be from any number of warehouses or manufacturing facilities, across multiple operating units or companies.

Application Logic

But then there is further integration that goes beyond the data level and must involve application logic. For example, our centralized order entry function, which has access to multiple sources for inventory, may need to apply certain logic to determine the priority sequence of locations from which to pull inventory. Do you always ship from the closest warehouse? Do you always ship from a certain location unless there is no availability? If so, how do you select the alternate location? These examples require more than simple sharing of data. They require the logic that applies business rules, decisions, and policies.

Presentation or Visualization

And finally there is the level of integration that resides in the presentation or visualization layer? When integrating multiple disparate business applications, do you concern yourself with a common and consistent look and feel? And how is access achieved? When there is a combination of legacy system with new web-enabled applications, do you front-end the legacy systems with a browser-based front-end?

There are several products on the market today that provide you with the ability to bring legacy applications to the Web. This is generally the least disruptive approach in that the underlying application remains the same, along with the application logic and process flow. This may be an acceptable alternative if in fact the existing "green screen" application generally supports your business processes. But it does nothing to improve the underlying application, so if the overall objective is also to provide additional functionality, you may be better off supplementing your existing application with a new web-enabled application that extends the feature/functionality of your existing system. Just how far you go will be determined by what you are really trying to accomplish.


SOURCE:
http://www.technologyevaluation.com/research/articles/integrating-all-information-assets-part-three-what-constitutes-integration-17242/

Financial Reporting, Planning, and Budgeting As Necessary Pieces of EPM Part One: Executive Summary

While ERP/accounting back-office systems and analytics have been inseparable ever since the idea of business automation via IT formed way back in the 1960s, they have nonetheless had different user experiences, evolutionary paths, and so on. Namely, although ERP systems have positively transformed many enterprises' business processes, many users have still been left feeling they were oversold due to the overwhelming notion that these systems inhibit access to the vital information "jailed" in the system. Many have inevitably felt that mixing real time back-office transactions with astute reporting is like mixing oil and water.

Business intelligence (BI)/analytics provides an environment in which business users receive information that is reliable, consistent, understandable and easily manipulated (i.e., flexible). C-level executives and middle management have always had a need to understand their business's performance regardless of good or bad economic times—while the output from BI might change, the need is always there. Particularly the recent massive demise of dot-coms, depressed economic times, and the stringent Sarbanes-Oxley Act (SOA) reporting regulatory requirements following up the high-profile corporate fraud scandals (e.g., Enron, Tyco, and WorldCom) have additionally increased executives' focus on understanding and managing corporate performance.

New disclosure rules are prompting companies to share information faster (for example, accelerated filling of 10Q quarterly statements and 10K annual reports, report sales of stock by executives [insider trading] within days of the transaction, expanded list of "significant events" to include changes in debt ratings, inclusion of financial results of partnerships in earnings reports, etc.), and sophisticated data-collection and data-analysis applications come in handy in that regard. Given that the BI tools have neither been terribly complex nor expensive to deploy, but have still been helpful in facilitating the decision-making process, they have become considered necessary rather than only a luxury. Also, decisions are nowadays increasingly made at ever lower levels in organizations.

Increased Need for Financial Reporting

On the other hand, the financial statement reporting process been important ever since the establishment of capitalist business practices. In addition to the tight economy's revelations of many companies' inability to proactively manage their financial performance (thus, repeatedly missing earnings and, in a knee-jerk fashion resorting time and again to last-minute layoffs, restructuring and operational expenditure freezes), its importance has particularly been emphasized with the outbreak of attention now being paid to the above-depicted accurate and certifiable reporting to external markets and government agencies.

However, creation, maintenance, and dissemination/publishing of financial statements (e.g., profit and loss [P&L] statements, balance sheets, and cash flow reports) have traditionally been maintenance-intensive tasks, with users expending significant effort just to meet basic requirements. Not to mention that everyone amongst the top brass always wants something more and different, such as different views, complex comparative reports, and drill-down analyses, but still within the familiar form of the financial statements.

Unfortunately, the financial reporting programs delivered with the traditional back-office financial management and accounting applications have proven only their rudimentary or pesky nature. Consequently, financial savvy users, having a strong preference to see results in the traditional P&L statement or balance sheet form, have long sought for ways to improve the report creation and maintenance process. On the other hand, the formatting and calculation constraints of the above statements, which require user-defined sorting and grouping, have been nearly impossible for generalist BI providers to fully accomplish.

This is Part One of a two-part tutorial.

Part Two will discuss challenges and make user recommendations.

Turning to ERP Systems

Most ERP products have a rich database, but, translating the data stored within the database to information useful for making enterprise decisions has proven difficult. With the availability of software analytic solutions, dozens of ERP providers can supply their customers with a valuable tool for harvesting the business value from the database. For example, the list of current back-office solutions whose GLs have been integrated with FRx financial reporting analytic solutions is impressive, and the following are just some more prominent ones: Advanced Data Systems, Best Software, Epicor Software, Expandable Software, Flexi International, Geac Enterprise Solutions, IQMS, Made2Manage Systems, MAPICS, McKesson, Ross Systems, Softrax Corporation, and naturally MBS Great Plains and Solomon (the integration with Navision and Axapta is under way). Other financial reporting providers like F9 or Timeline have almost as impressive a list of ERP partners.

As an example, MBS for Analytics—FRx (formerly FRx Financial Reporter), with its spreadsheet-like interface, can consolidate financial data from disparate accounting systems even if they use different code structures, fiscal years, or server sites. By pulling information already set up in the GL, the product automatically understands the fiscal periods, chart of accounts, detail transactions, and various types of balances. Due to built-in accounting intelligence, it even recognizes concepts such as current and year-to-date amounts, debit versus credit balances, positive and negative variances, and posted and un-posted transactions. Furthermore, users can leverage the rows, columns and formulas that they may have created in Excel and import the information, with all data intact, directly into FRx.

The key tenets of FRx's flexibility have been the following three building blocks:

1. Row format, which lets users specify the data source and what they want to do with each row of a report. By using a link to the GL, users can select individual accounts, a range of accounts or a list of non-continuous accounts to be included in a report. Once created, a row format can be saved and used again as required.

2. Column layout, which lets users specify the data source and select the type of column they want from a list. Combined with row format, Column Layout lets users include period actuals, budget information, or other types of data in a report, either from the GL or from another data source like a spreadsheet. Math formulas across columns can be applied to identify variances, projections, or percentages. Like with row format, once created, a column layout can be saved and used again.

3. Reporting trees, which lets users create a hierarchical picture of their organization to understand or change their organizational and reporting structures. An auto-build function constructs reporting trees directly from the organization's chart of accounts, while an intuitive drag-and-drop functionality enables users to create alternative structures and multiple rollups of various accounts without having to make costly modifications to their GL or charts of accounts. Once created, a reporting tree can be saved and used again.

In addition to the on-the-fly reports creation option, application servers provide report scheduling and automatic e-mail report distribution. Using one of many customizable report templates, users can often get started creating relevant financial reports right away using the building-block approach and auto-build functionality, without much help from IT resources or other technically-minded personnel. Then, these reports can be posted to the Web or be sent via e-mail to be accessed immediately by on-site and off-site users alike, while a connection to the GL is not required.

GL Considerations

Despite many commonalities, every GL has its own fingerprint uniqueness. To illustrate, MBS Solomon's (which has long featured a built-in version of the FRx Desktop and FRx Forecaster) GL account and sub-account numbers can be up to thirty characters in length, whereby the main account number can be up to ten characters, and the remaining twenty characters can include up to eight user-defined segments. GL transactions can be entered using several types of transaction batches, including non-recurring, recurring, manual and one-sided adjustment, and the GL account determines whether the transaction will operate in multi- or single-company mode. Transactions can be entered for any prior fiscal period or year as well as for future periods, which allows for things such as installments and prepayments to be managed at a single time, rather than month after month.

On the other hand, MBS Navision's chart of accounts (where integration is slated for Navision 4.0, some time in 2004/2005) lets users define an unlimited number of "dimensions" and "dimension values" at any time. A dimension is data that users can add to an entry as a kind of marker so that the program can group entries with similar characteristics and retrieve these groups for analysis purposes. Dimensions are not limited to the GL accounts, since they can be set on all master records stored in the database such as customers, vendors, items, fixed assets, and so on. Dimension values are sub-units of dimensions. For example, a dimension called department can have sub-units such as sales, administration, and so forth. This is a powerful concept and tool, which allows nearly unlimited configurations to meet a company's needs and business processes, but it will certainly present some challenge to the integration to FRx.

Translating Strategy into Objectives through Forecasting

In fact, planning and budgeting have become a means of translating strategy into a coherent set of objectives, as well as a basis for assessment of achievement. As planning and budgeting should be a collaborative process (a forum on the future direction of the organization), there have been indications that even during unrelenting economic pressures, corporate managers are still seeing value in providing desktop portal views of key business process analytics to an increasing number of corporate workers. As a result, many financial executives have been marking active financial planning tools as a top investment. On the other hand, the majority of those annual plans are still completed in Excel spreadsheets, which wreaks havoc for business analysts and IT personnel as they try to figure out complicated links and how to import and export data to and from the spreadsheets.

Contrary to that, the collaborative capabilities offered by software analytic products should save time and help improve the quality of the final budget, making it more realistic and accurate. Users can collaborate using features such as automatic e-mail notification of upcoming deadlines and a centralized bulletin board where goals, objectives, business tactics and instructions are posted for enterprise-wide access. Through the use of memos, notes and attachments, managers can understand the rationale behind important numbers and assumptions made by other departmental managers, reducing or eliminating time spent in meetings. Furthermore, the software should let department managers interact with each other to insure their budgets complement each other's. For example, if a department budgets for a new program that impacts other departments, all budgets can reflect the impact of the new program. The software should also facilitate the reorganizing of the company's chart of accounts, since rollups are parent-child relationships that control how the posting data is summarized.

Forecasting software streamlines many of the tasks that comprise the budgeting process, including individual creation of budgets, changing the budget model, budget consolidations, and reporting and collaborating with interrelated departments to improve the chances of achieving set goals. This streamlining of tasks gives managers more time to construct a thoughtful budget that is based on valid data and assumptions (e.g., headcounts, project schedules, and costs. Can be changed and simulated to reflect different economic assumptions) and therefore be more predictive of the future. Accessing up-to-date and historical information from the general ledger and existing financial reports, users can budget and plan with greater precision.

Forecasting software should also consider (bearing in mind that this list is by no means complete):

* Expense budgeting, allows customers to define templates specific to cost centers, and thereby enables managers to focus on the important information.

* Human resources, which allows a company to better understand the effect of salary adjustments, bonuses, overtime, and benefits given that employees often account for the highest part of the expenses in a company's budget.

* Capital expenses, which lets the company standardize the accounting of capital expenditures by cost centers.

* Revenue planning, allows customized accounts and formulas to be used to calculate revenues and cost of sales, whereby formulas can be customized to meet organizational needs such as production, staffing, raw materials, and outside revenue planning.


SOURCE:
http://www.technologyevaluation.com/research/articles/financial-reporting-planning-and-budgeting-as-necessary-pieces-of-epm-part-one-executive-summary-17115/

Information Builders Did It iWay

Information Builders (IBI, privately held) has announced plans to spin off its middleware technology group (which develops and supports the EDA middleware product) into a new wholly owned subsidiary named iWay Software. The move is designed to allow Information Builders (IBI) to concentrate on the WebFocus and Focus business intelligence products, while allowing iWay to handle e-business integration using its suite of iWay software products (many based on EDA technology) and other former IBI offerings, including the SmartMart data warehousing suite.

According to Gerald Cohen, CEO of both Information Builders and iWay Software, "We carefully considered all our options for effectively supporting and growing our business intelligence and integration product lines before we entered into this milestone decision. Establishing a subsidiary will not only streamline Information Builders' ability to respond to the needs of its customers, but it will also give us an opportunity to brand our multiple product lines more effectively, thereby maximizing efficiency in the marketplace."

President John Senor, formerly vice president and general manager of the middleware product line and founder of the EDA division, will lead the new company, which is comprised of Information Builders' former Middleware Technology Group. The new company will focus on delivering rapid e-business integration solutions built on its newly announced suite of enterprise integration products. "As a part of Information Builders, we delivered rock-solid technologies that could integrate information from over 120 different sources and operating environments. This includes all legacy data, relational databases, ERP, and application products," said Senor. "That capability is critical for e-business, because e-business requires comprehensive access to all information assets in the enterprise."

Market Impact

iWay Software hits the ground running with more than 25 technology and services partners, including IBM, Oracle, NEON (New Era of Networks, not NEON Systems), i2 Technologies, Informix and others, who are participating in a variety of cross-licensing, co-marketing, and OEM agreements. Other vendors in this market space will have to make sure that they keep up with iWay, since the new spin-off starts out with an established customer base (from the EDA product, which has been on the market for ten years), name recognition in accounts (particularly due to the Focus products), existing agreements with partners, and an already-trained consulting staff.

As noted in many previous TEC articles, e-Business Integration is definitely the hot area at the moment. It is critical to firms attempting to integrate legacy data into web platforms, especially for access to historical data used in customer relationship management (CRM), and supply chain management (SCM) applications. EAI, or enterprise application integration, is the term commonly applied to this type of application, and it is clearly not a passing fad. Companies are rushing madly to "webify" their applications, and any software product that speeds implementation time and/or allows access to a "difficult" data source will have a leg up on the competition.


SOURCE:
http://www.technologyevaluation.com/research/articles/information-builders-did-it-iway-16322/

Glossary of Enterprise Applications Terminology Part One: Accounts Payable Through Internet

Enterprise resource planning (ERP) was an important step in an ongoing evolution of computer tools that began in the 1960s. Each evolutionary step is built on the fundamentals and principles developed within the previous one. As systems developed over time, a continuous stream of new terminology surfaced.

This is a glossary of those terms.

For terms not covered here see The Lexicon of CRM Part 1: From A to I , Part 2: From J to Q , and Part 3: From R to Z.

Accounts Payable through CRM

accounts payable (AP): The value of goods and services acquired for which payment has not yet been made.

accounts receivable (AR): The value of goods shipped or services rendered to a customer on which payment has not yet been received. Usually includes an allowance for bad debts.

advanced planning and scheduling (APS): Techniques that deal with analysis and planning of logistics and manufacturing over the short, intermediate, and long-term time periods. APS describes any computer program that uses advanced mathematical algorithms or logic to perform optimization or simulation on finite capacity scheduling, sourcing, capital planning, resource planning, forecasting, demand management, and others. These techniques simultaneously consider a range of constraints and business rules to provide real-time planning and scheduling, decision support, available-to-promise, and capable-to-promise capabilities. APS often generates and evaluates multiple scenarios. Management then selects one scenario to use as the "official plan." The five main components of APS systems are demand planning, production planning, production scheduling, distribution planning, and transportation planning.

APICS: A nonprofit educational organization consisting of over 70,000 members in the production and operations, materials, and integrated resource management areas.

application Software: A program that performs a task or process specific to a particular end-user's needs, or solves a particular problem. Enterprise applications are typically large-scale business systems that organizations use to manage their operations.

application programming interface (API): A set of routines, protocols, and tools for building software applications or for communicating with programs or other systems. A good API makes it easier to develop a program by providing all the building blocks that a programmer needs Although APIs are designed for programmers, they are ultimately good for users because they guarantee that all programs using a common API will have similar interfaces, which makes it easier for users to learn new programs. On the other hand, many enterprise applications vendors provide APIs for integrating other applications with their systems.

application service provider (ASP): A third-party entity that manages and distributes software-based leased services and solutions to customers across a wide area network from a central data center. In essence, ASPs are a way for companies to outsource some or almost all aspects of their information technology needs.

architecture: A structured set of protocols that implements a system's functions.

available-to-promise (ATP): The uncommitted portion of a company's inventory and planned production, maintained in the master schedule to support customer order promising.

back scheduling: A technique for calculating operation start dates and due dates. The schedule is computed starting with the due date for the order and working backward to determine the required start date and/or due dates for each operation.

bill of material (BOM): A listing of all the subassemblies, intermediates, parts, and raw materials that go into a parent assembly showing the quantity of each required to make an assembly.

browser: Software used on the Web to retrieve and display documents on-screen, connect to other sites using hypertext links, display images, and play audio files.

business intelligence (BI): Sets of tools that provide graphical analysis of business information in multidimensional views thus enabling people to make better decisions and improve their business processes.

business-to-business e-commerce (B2B) (A): Business being conducted over the Internet between businesses. The implication is that this connectivity will cause businesses to transform themselves via supply chain management to become virtual organizations, reducing costs, improving quality, reducing delivery lead time, and improving due-date performance.

business-to-consumer sales (B2C) (A): Business being conducted between businesses and final consumers largely over the Internet. It includes traditional brick and mortar businesses that also offer products online and businesses that trade exclusively electronically.

capable-to-promise (CTP): The process of committing orders against available capacity as well as inventory. This process may involve multiple manufacturing or distribution sites. Capable-to-promise is used to determine when a new or unscheduled customer order can be delivered. Capable-to-promise employs a finite-scheduling model of the manufacturing system to determine when an item can be delivered. It includes any constraints that might restrict the production, such as availability of resources, lead times for raw materials or purchased parts, and requirements for lower-level components or subassemblies. The resulting delivery date takes into consideration production capacity, the current manufacturing environment, and future order commitments. The objective is to reduce the time spent by production planners in expediting orders and adjusting plans because of inaccurate delivery-date promises.

capacity requirements planning (CRP): The function of establishing, measuring, and adjusting limits or levels of capacity. The term CRP in this context refers to the process of determining in detail the amount of labor and machine resources required to accomplish the tasks of production.

client/server system: A distributed computing system in which work is assigned to the computer best able to perform it from among a network of computers.

client: In information systems, a software program that is used to contact and obtain data from a server program on another computer. Each client program is designed to work with one or more specific kinds of server programs, and each server requires a specific kind of client. A Web browser is one type of client.

computer-assisted software engineering (CASE): The use of computerized tools to assist in the process of designing, developing, and maintaining software products and systems.

computerized maintenance management systems (CMMS): Automated software systems for handling maintenance work orders, as well as associated inventory, purchasing, accounting, and human resources functions. In some industries—particularly process production, in which manufacturers look to optimize use of capital-intensive equipment—maintenance management systems play a leading role as the enterprise system. Maintenance management systems have similar basic functionality, including:

1) use of work orders for preventive and predictive maintenance,

2) equipment recording and tracking,

3) inventory control,

4) scheduling labor and resources, and

5) purchasing.

corporate performance management (CPM): An overarching term that describes the methodologies, metrics, processes and systems used to monitor and manage the business performance of an enterprise. Applications that enable CPM translate strategically focused information to operational plans and send aggregated results.

cost of goods sold (COGS): An accounting classification useful for determining the amount of direct materials, direct labor, and allocated overhead associated with the products sold during a given period of time.

customer relationship management (CRM): Software systems that range from simple, off-the-shelf contact management solutions to high-end interactive selling suites that combine sales, marketing, and executive information tools. These include product configuration, quote and proposal management, and marketing encyclopedias. Some systems extend functions to include complex pricing, promotions, commission plans, team selling, and campaign management. Enterprise-level solutions installed at large companies with hundreds or even thousands of users have capabilities for call center and help desks; field service; forecasting; and analysis.

Database through Internet

database: A data processing file-management approach designed to establish the independence of computer programs from data files. Redundancy is minimized, and data elements can be added to, or deleted from, the file structure without necessitating changes to existing computer programs.

database management system (DBMS): The software designed for organizing data and providing the mechanism for storing, maintaining, and retrieving that data on a physical medium (i.e., a database). A DBMS separates data from the application programs and people who use the data and permits many different views of the data.

data warehouse: A repository of data that has been specially prepared to support decision-making applications.

discrete manufacturing: Production of distinct items such as automobiles, appliances, or computers.

e-Business: The generic name given to any type of business conducted using the Internet from online trading to self-service.

engineer-to-order (ETO): Products whose customer specifications require unique engineering design, significant customization, or new purchased materials. Each customer order results in a unique set of part numbers, bills of material, and routings.

enterprise application integration (EAI): The unrestricted sharing of data and business processes throughout the networked applications or data sources in an organization, since early software programs in areas such as inventory control, human resources, sales automation and database management were designed to run independently, with no interaction between the systems. There are four major categories of EAI:

1) database linking: databases share information and duplicate information as needed;

2) application linking: the enterprise shares business processes and data between two or more applications;

3) data warehousing: data is extracted from a variety of data sources and channeled into a specific database for analysis; and

4) common virtual system: the pinnacle of EAI; all aspects of enterprise computing are tied together so that they appear as a unified application.

enterprise asset management (EAM): A term used by maintenance management software vendors to connote the wide-ranging functionality that their systems include, for example inventory management and financials. A company's total assets might include labor, tools, equipment, materials, and information. The goal of asset management is to optimize asset use and manage all maintenance efforts involved in making assets as reliable, accurate, and efficient as possible. A further crucial element in enterprise wide asset management is integration with financial, human resources, and purchasing functions, as well as production, material requirements planning, and enterprise resources planning systems.


SOURCE:
http://www.technologyevaluation.com/research/articles/glossary-of-enterprise-applications-terminology-part-one-accounts-payable-through-internet-17685/

Attributes of Sarbanes-Oxley Tool Sets Part Two: Information and Communication, Monitoring, and Startup Tips

The Sarbanes-Oxley Act (SOX) placed new requirements on American companies to ensure the integrity, reliability, and accuracy of financial reporting and corporate disclosures. While you could do this on your own or manually, why reinvent the audit controls wheel? Automated tool sets and repositories to facilitate SOX compliance are available in ample numbers. But like any piece of software, you have to know what to look for to meet your organization's expectations and avoid disappointments. This research note examines critical attributes of SOX tool sets, discussing how you can utilize them effectively to maximize the return on your investment of time and money.

Part One examined the first three components of the COSO Integrated Framework relative to selecting a SOX tool set.

Part Two discusses the information and communication, and monitoring components from a similar perspective and provides some tips for kicking off the tool set selection process.

What is COSO?

COSO stands for Committee of Sponsoring Organizations of the Treadway Commission. It is a voluntary private-sector organization dedicated to improving the quality of financial reporting through business ethics, effective internal controls, and corporate governance. The Securities and Exchange Commission (SEC) ruled that management must base its evaluation on a suitable, recognized control framework established by a group that has followed due-process procedures, including the broad distribution of the framework for public comment. Furthermore, the SEC points out in its final rule that the COSO Internal Control—Integrated Framework, which is depicted in the three-dimensional diagram to the right, satisfies this requirement. Accordingly, the majority of organizations have adopted this framework as the basis for compliance with Section 404 of SOX, namely Management Assessment of Internal Controls.

When evaluating SOX tool sets, doesn't it make sense to determine how well the proposed software satisfies critical components of the COSO framework? Of course it does. The remainder of this note examines the five components of the COSO framework, outlining the key characteristics and attributes you should consider in selecting a SOX tool set. Specifically, these components include:

* Control environment

* Risk assessment

* Control activities

* Information and communication

* Monitoring

A brief description and introduction, as denoted in italics, is provided of how each component will assist in achieving internal control objectives as depicted in the second dimension (top level view) of the framework. These control objectives provide for the following:

* Obtaining the efficiency and effectiveness of operations in meeting business objectives to include performance and profitability goals

* Ensuring the accuracy and reliability of financial reporting

* Verifying compliance with applicable laws and regulations

The third dimension (front to back view) of the framework includes the units and activities of an organization to which internal controls pertain. Internal controls are relevant to an entire organization and to any of its units, activities, and processes. Accordingly, you must apply internal controls uniformly across an organization's units and activities. This characteristic is common to all components and is mentioned here to ensure that you can integrate the selected SOX tool set into all levels of an organization and equally apply it in a top-down approach. It would make little sense to have a tool set that could only operate at a corporate level without being able to deploy it at a division or apply it to a process. As with any software selection project, the decision makers must be comprised of a diverse cross section of an organization's users to achieve this characteristic.

Information and Communication

The information and communication component of the COSO framework consists of processes and systems that support the identification, capture, and exchange of information in a form and timeframe that enable an organization to perform their responsibilities. Simply put, this means providing the right information to the right people, at the correct level, on a timely basis. Similarly, communication processes must be in place to permit people to discharge their responsibilities.

First and foremost, the SOX tool set must be able to model the performance of the organization to include the specific processes used to generate or contribute to the financial reporting of the organization. In so doing the tool set can then support real time activity audits. Just as you would map your manufacturing processes when selecting an ERP package, you must identify these critical financial processes sufficiently to verify that a reliable electronic image of your business can be defined in the tool set.

It stands to reason that your accountants need to verify that the tool set is in compliance with GAAP. Failed audits need to be highlighted for immediate follow-up. Reconciliation procedures must reside in the tool set to provide immediate notification regarding audit failures. The ability must exist to lock down the approved tool set to prevent unauthorized alteration to the model.

Finally, the tool set should be able to support the audit function in the following ways:

* Be "resource-centric" and understand corporate resources and relationships.

* Audit the administrative systems underlying business operations.

* Audit manual transactional input of transactions and support operations reviews and individual transaction processing.

* Integrate with other systems (such as the inventory management system) and cross-check the system counts against individual transactional processing product accumulations.

* Support internal and external audits by providing detailed logs of each transaction and the results of the business-model audit. The system will check every transactions, every resource and will be able to provide statistical sampling when needed for operations and personnel reviews.

* Log each activity that takes place as a record of accounting events and transactions.

* Provide alerts or warnings for appropriate internal management of activities not meeting the business model or new regulations coupled with instantaneous reporting and documentation of these alerts/warnings.

Monitoring

Monitoring consists of the process that assesses the quality of internal control performance over time. A control system needs to be monitored to ensure that it continues to operate effectively and as intended. Without continual and effective monitoring, a control process may fall into a state of disrepair or not be executed altogether.

Consequently, a SOX tool set must run in real time on a 24x7 basis and unattended. You must be able to systematically monitor all activities and transactions corporate wide, with exception reporting used to identify control lapses and gaps. These transactions must be audited both operationally and financially against the business model. This implies a SOX tool set must have the flexibility to incorporate the rules of your business. To facilitate the recording and editing of these rules and to avoid hard coding or programming changes, you should consider a knowledge-based methodology, external to the tool set. As a result, approved rules can be entered without major effort from an organization's technical staff.

Business activity monitoring within a corporate information environment is evolving quickly. SOX, in many cases, requires that a tool set provide continuous activity monitoring, thereby allowing instant insight into corporate performance. As previously noted in the Information and Communication section, the sooner red flags are raised, the more time management has to evaluate and correct financial shortcomings.

Let's look at a simple example of operational/financial interaction when dealing with the purchase of an item to illustrate the monitoring component. The first rule is that the item purchase be from a known, legitimate, supply resource with which the corporation has a relationship. The same rule applies to the reason for the purchase. The internal resource to which the item will go may be product inventory, cost center inventory, or equipment or services. Depending on GAAP rules, the nature of the purchase and the business policies of how to allocate the cost of different purchases, the tool set must be able to compute auditable financial entries into the appropriate accounts. It must also update the supplier relationship with an accrued payable to verify the transaction when an invoice is received and posted into accounts payable.

The rules vary for different types of internal resources but all are available in resource-centric control files. On the other hand, when rules are changed by an authorized person, the resource-centric file will contain the new rules. It will also document who authorized the change, when, and the commencement date.

The same facility can be used for sales transactions with similar rules applied consistently from estimation, order entry, shipment and invoicing as to pricing, discounting, cost of sales and the reduction of product inventory, the computation of sales taxes to be collected and paid to the government and where applicable accrual of sales commissions. Manual adjustments and other infrequent transactions must undergo similar verification.

The resource-centric control files give everyone a cohesive picture of all the rules that apply to each type of resource. For example, product/inventory control files will contain the rules for sales, purchases, and all price, cost, and volume adjustments.

The timeliness of information distribution is critical and can take several forms such as alerts and warnings on "dashboards," e-mails, and text pages on a phone or PDA. E-mailing of control exceptions to the appropriate user and next-level supervisor must receive consideration, so problems can receive prompt attention and resolution. Additionally, a query language capability is a useful and necessary facility to satisfy ad hoc reporting requirements for analysis and on-demand information needs to allow those accountable and responsible to monitor, validate, and use the information collected.

Some words of caution regarding internal controls are warranted. The type of continuous monitoring process needed for SOX will put an additional strain on your control processes. You will need to have consistent, verifiable, and monitored internal processes regarding problem resolution when dealing with business activity defects. After error detection, the reconciliation process begins with understanding who's responsible and accountable for correcting the problem and when must it be corrected. Of course, someone, most likely in an audit function, will need to "mind the store" in this regard. The tool set must also provide the necessary support in this area.


SOURCE:
http://www.technologyevaluation.com/research/articles/attributes-of-sarbanes-oxley-tool-sets-part-two-information-and-communication-monitoring-and-startup-tips-17127/