This topic is shared to provide an overview of Data Conversion for Oracle ERP.

Approach used for Data Conversion

1. Conversion Data Mapping ( map to specify the data of legacy system –> data of oracle ERP system )
The data mapping process provides detailed lists of the data sets and data elements that will need to be moved into the Oracle ERP tables during the data conversion.

During this process, some decisions will need to be made with regard to obtaining information needed by the target application that may not be present in the old system(Legacy System ). Decisions like ->>Default settings, user input, and new data entries are some of the issues that must be addressed during this phase.
The output of this activity is data mapping tables that show what is needed for the Oracle target application processing to meet business operational requirements and where these data elements will come from. Based on this mapping, a design of the legacy data extract is defined.

2. Download Programs ( programs to extract data from database and insert into the Flat file )
These programs are used to extract the identified conversion data elements from the current systems in the form of an ASCII flat file. This can be done with a 3rd party tool or programmatically done within the lagacy database systems.carefull planning must be done before the flat file created as the data can be placed in the order its extracted , type of delimeter used( either ,(comma) or | (pipe) or anything other, number of records, etc.

3. ASCII Flat File (Flat file / Text file)
Most database or file systems output data in text form. A comma or space delimited, variable or fixed format data file from the existing system should be generated. If you cannot find a way to produce clean text data, try generating a report to disk, using a text editor to format your data.
One of the outputs of conversion data mapping is to identify the legacy data element data types and precision(example decimals and dates specifics).

Once the conversion data mapping is done, you should know if there are inconsistencies between the legacy data types and the requirements for the Oracle data types. If there are translations that need to take place, these translations can be performed on the legacy system prior to creating the extract or in an interface table. Also, if you are creating a fixed length extract file, you need to take into account the precision level of decimal numbers.

4. Upload Program
Once data has been put into an ASCII EBCDIC flat file and physically moved onto the same computer that has the Oracle RDBMS, the next step is to load the data into a relational database environment.
Programs must be written and run to move data, validate data, and insert/update standard values into default fields. Usually a single loader program is written for each data table being loaded.

5.Interface Tables ( know more about Interface tables here )

a. Description of Interface Table
The detailed technical description of any interface table that the data is placed into from the ASCII flat file is prepared. An interface table that mimics the production table into which the data will eventually be loaded into should be defined. This allows you to manipulate the data as needed before loading the legacy data into the production tables.

b. Creation of Interface Table
Before loading the Oracle Application production tables, the legacy data should first be loaded into temporary or interface tables. The interface tables provide a location for you to manipulate and translate the data as needed before validating the data and loading the application production tables. These temporary interface tables need to be built before you run the loader script to populate these tables. The interface tables may be standard Oracle Application interface tables or may be custom interface tables.

6. Translation Programs
These scripts are developed to translate data from the existing system format into useful data for the Oracle target application. An example of this might be taking the date format that exists in the legacy system and converting it into an Oracle format. There may be several or no translation programs, depending on both the type of data coming across and the format of that data.

7. Interface Programs ( example )
The interface program scripts are used to populate the production database. The purpose of the interface programs is not only to move the data to the target tables but also to validate the data that would be validated by the form in the target application if the data was converted manually.

8. Application Production Table
This is the final production data table where the converted data resides. These tables are identified early on when doing the initial data mapping. These tables drive some of the translation programs that must ultimately ensure that 100% of the information that the target applications require is present in the final data structures.

9. Testing
This test plan has been integrated into the entire conversion process so that, even during the pre-conversion steps, some type of validation reports are generated from the legacy systems, to be compared later with the converted data.
The approach taken is to use as many standard reports as possible that are available in the legacy and target system for the final data validation. If no reports support the validation requirements, then custom scripts will need to be created for specific validation purposes.

10. Write and Perform Conversion Execution Plan
The conversion execution plan is the execution document that is to be followed when performing the actual conversion. This document is specifically tailored for the <Company Short Name> conversion.

Types of business intelligence tools
The general categories of business intelligence tools are:

1.Spreadsheets[1]

2.Reporting and querying software - are tools that extract, sort, summarize, and present selected data (

Open source software

• Eclipse BIRT
• Agata
• ReportProject
• JasperReports
• Pentaho
• GNU_Enterprise (reporting sub-package) Etc…

Commercial software

• Infocaptor
• Alchemex
• Actuate
• Cognos BI
• Crystal Reports
• InetSoft(InetSoft Style Report)
• Information Builders
• FOCUS and WebFOCUS
• LogiXML
• Microstrategy
• Oracle XML Publisher (now known as ‘BI Publisher’ )
• Business Objects
• Telerik Reporting
• SQL Server Reporting Services
• Proclarity
• RepGen.Net Etc…

3. OLAP

There are many vendors providing OLAP tools

4.Digital Dashboards

here I can recommend one very easy and powerful Dashboard tool called Infocaptor .I keep recomending this because its having all of the same power features of reporting and Dashboards tool as any other top (read expensive) tools .

5.Data mining

6.Process mining

A software framework for the evaluation of process mining algorithms has been developed at the Technical University of Eindhoven and is available as an open source toolkit.

7 .Business performance management

what is BPM ?

Business performance management (BPM) (or Corporate performance management, Enterprise performance management, Operational performance management) is a set of processes that help organizations optimize their business performance. It is a framework for organizing, automating and analyzing business methodologies, metrics, processes and systems that drive business performance.

BPM is seen as the next generation of business intelligence (BI). BPM helps businesses make efficient use of their financial, human, material and other resources

read more related topics at http://en.wikipedia.org/wiki/

please comment and let me know if you liked this article.

brief ( and important ) details of WorkFlow tables.

lets first learn some definations.

A process activity is a modelled workflow process, which can be included as an activity in
other processes to represent a sub–process.

A notification activity sends a message to a performer.

A folder activity is not part of a process,it provides a means of grouping activities.

below is the most important tables for Work Flow module.

WF_ACTIVITIES stores the definition of an activity.
Activities can be processes, notifications, functions or folders.

WF_ITEMS is the runtime table for workflow processes
Each row defines one work item within the system.

WF_ITEM_ATTRIBUTES table stores definitions of attributes associated with a process.
Each row includes the sequence in which the attribute is used as well as the format of the attribute data.

WF_NOTIFICATIONS holds the runtime information about a specific instance of a sent message.
A new row is created in the table each time a message is sent.

find more such Quick info about ERP tables at http://www.appsbi.com/

For decades, companies have been spending millions of $$$’s on systems to streamline and automate the execution of the business plan. Over time, these systems have become more and more integrated within a companies operations and between business partners. However, due to the granularity of the data stored in these systems, management has difficulty accurately monitoring how well the business plan is being executed.

The alternative to making decisions based on feelings or assumptions is often spending hours each month “summarizing reports” to get a macro view of their environment. Often the job of monitoring the success of business practices is so tedious that managers often fore-go the process altogether and try to rely on their gut feelings or “biggest daily headaches” to drive their decision making process. When a manager does need hard data to back up their assumptions, they have to wait for weeks for the backlogged IT department to give them a report (hopefully the right one).

Data Warehouseing Advantages

Dimensional Model based data warehousing is an enabling technology that can put real answers in the hands of your management team in an efficient and timely manner.

Data Orientation- Dimensional modeling provides meaningful data to end users by reorganizing transactional data to a dimensional structure, suited for reporting instead of operating efficiency.

Complexity- By applying consistent and intelligent business rules to raw data, information in the dimensional model can be presented in a simple and straightforward manner, instead of the complex structure found in the transaction systems.

Integrity - By putting transactional data through rigorous tests and applying business logic specific to the companies operations, data warehouse users can be certain that they are viewing complete, accurate, and consistently defined information.

Sources and Accessibility – Instead of having to go to the various information brokers in your organization to get information from various subsystems, dimensional modeling allows disparate data from any enterprise application to be brought together and presented in a “one-stop-shop” approach. Many OLAP (On Line Analytical Processing) tools are deployable over an intranet (or extranet), and can be configured to provide an experience that is unique to each user – giving them access to what they need – and cutting out the noise that they don’t.

Focus – With data organized for reporting, analysis tools can be used to efficiently ask questions about the data, providing insight into how the business operations are really doing. By utilizing one of the many powerful OLAP (On Line Analytical Processing) tools, managers can view the information they specifically want to see – and if necessary adjust the level of detail or type of information that is included in the report.

The Data Warehousing Process

At Integration Management, we believe the key to successful decision support application development and maintenance is an effective and efficient data warehousing process. To make the end product useful, specific attention must be given to the configuration of back-end processes. To make these processes more effective over time, it is important to have back-end processes that can evolve as the business model becomes more understood or changes over time. That is why nearly all IHDS utilities were designed to operate from easily configurable metadata.

Figure 1 - Data Warehousing Process

Readying Source Data

The process of transforming transactional data from multiple sources into an integrated, analysis oriented dimensional structure begins with the replication of transactional data in a SQL Server data store. A key element of this step includes determining the frequency in which the SQL server data store is updated with live data.

Business Rule Application

The heart of a good data warehouse is the process of applying business rules to the raw transactional data to better model the business processes. It is in this area that organizational knowledge and business procedures that are kept outside of the transaction systems are applied to the transaction systems data, creating a more complete picture of what is happening.

Once the required data is “local” to the warehouse in the replicated data store, “scrub” business rules can be applied to the data to search and respond to incomplete or invalid data. When the data set is acceptable, business rules are used to categorize and classify objects and events in the transactional data.

An example of a valuable business rule is the ability to enforce referential integrity on the transaction data. Since some managed care applications do not utilize a true relational database structure, the link between important records is often lost. For example, the provider identified on the claim may not even exist in the provider file. Depending on the safeguards used during the data entry or claim adjudication process, this data condition may not be caught. When standard reports are developed for this particular claim, provider information will not be included, and in some situations, claim may not even be displayed.

After the scrubbing and classification process are complete, the process of mapping the data to the dimensional structure and calculating required business measures is executed. The dimensional structure transforms the data from a complex structure keyed and organized according to the processing of transactions to one that is more intuitive to business analysts, representing how they view the business critical data in your organization.

Multi-Dimensional Modeling

Once the data has been organized in the “Star Schema” dimensional model, it is ready to be used for reporting and analysis. The dimensional data can be used as the data source for various reporting applications such as Crystal Reports and Cognos Impromptu. Multi-dimensional cubes can also be generated to take advantage of OLAP tools such as Cognos Powerplay or Proclarity.

The key to dimensional structure is the organization of data into dimensions and facts. Dimensions hold the “qualitative” characteristics of your data, such as

* Members age, group, plan for specific claim,
* Dates like service, claim, post, and check date
* Claim diagnosis or procedure codes or categories
* Relationships such as IPA, PCP

Facts store detailed or summarized qualitative data that is either detail or summarized values of specific numeric or time data associated with your transactional data. Examples include:

* Cost values on transactions (claim paid amount, claim billed amount, capitation paid amount, etc)
* # of occurrences of specific events (admits per 1000, deliveries per 1000, member months)
* time between events (inpatient days, claim receive date to check date)

After the data is organized into facts and dimensions, it is ready for business analysis driven query development and OLAP tool integration. Records are efficiently linked providing short query time even for the largest of data sets.

read more

True value of Business Inteligence comes from recognizing and harnessing the power of technology to help change the way you do business. After all – unless there are real decisions made with the information provided by a data warehouse, all you have is a data warehouse, not a decision support application.

By utilizing information and insight gained from your data warehouse and analysis tools, The goal should be to help you keep track of the KPI (key performance indicators) in your business, and help you put into action changes that will improve your business.

The Business Intelligence Life Cycle

Raw Data Capture

Instead of using assumptions based on anecdotal feelings or rumors, decision cycle starts with raw data – the piles of data that is captured as part of your day to day operations. As the normal (and sometimes abnormal) processes of your business are being executed, data such as claims, contracts, authorizations and member contacts are generated from within your organization.

Deriving Information from Business Rules

Next, using input from across your management team and our industry experience, we identify key performance indicators that help measure how well your business is executing. While many of these metrics are consistent across the healthcare industry, how they are calculated may differ from company to company based on different regulator requirements, variations in business models, and unique organizational mission.

We understand that what may be critical to one company may not be so important to another. Our goal would be to find the critical 10-15 measures that indicate how your organization is doing. This “dashboard” of measures would help provide a comprehensive view of the effectiveness of the business model and operations. Examples include: Per Member/Per Month calculations, inpatient days, and claim expense.

Once the key measures are identified, as well as an understanding of how they are to be calculated is defined and agreed upon, the IHDS system can be configured to provide them in ways that make most sense to the management team.

Transactional data that is captured in the first stage of the decision cycle can be transformed, aggregated and presented using the IHDS utilities and methodology.

From the information base, questions about the measures can be asked. The resultant answers allow business analysts, managers and executives to look for trends, top performers, bottom performers, segmentations, correlations, etc.

Business User Oriented Analysis

At this point, the key is providing decision makers with the analytical tools necessary to gain insight from the data warehouse information. Trends, anomalies, and the statistical distribution of these measures can be researched and understood. With the summary and detail information from the data warehouse at their fingertips, management can efficiently monitor the performance of the business.

Developing and Executing Smart Initiatives

Making decisions that truly change the ways your business operates is the goal of our Business Intelligence Services. With our understanding of managed care operations and business model, we can help your management team come up with new initiatives or business practices that will clearly affect your performance, and ultimately your bottom line.

As these changes take place, actual results can be monitored as new data is collected from ongoing business operations. With the ability to monitor the results, initiatives can be evaluated, tweaked, and even scrapped as necessary.

Let’s look at a meaningful claims expense example.

Data accumulation during normal business operations. Whether via EDI or manual entry, claims are entered and adjudicated in your managed care transaction system all day and every day. In order to perform the adjudication process correctly, many data elements must be included on the claim as the claim system matches various benefit, contract, provider and other reference information. All this raw data is accumulated during the normal processing of claims, one of the primary business practices of every health plan.

Transformation of raw data into information. Each night or weekend, pertinent claim data, captured above, flows into the data warehouse. During this process, many business rules execute to transform the raw data into an analysis oriented structure.

Data Scrubs: Data scrubs do the work of ensuring the raw data’s integrity. For example, let’s assume the provider on some claims is not in the master provider table. Instead of leaving this field blank, we can assign a value called “provider not found”, which ensures that the claim information is still considered in the final warehouse measures. Another scrub might be for dates of service that are in the future, produced by a typographical error in the claims department. Instead, this date is changed to the current date.

Categorization: From the claim data, data points are added, adjusted, changed, realigned, or deleted to “categorize” claims the way you need to analyze them. For example, you may want to determine whether the claim is in-network, or out-of-network. However, the process to determine subtypes of out-of-network claims is complicated, based on a series of special codes and a vendor or provider list. These rules can be modeled as business rules in the data warehouse, and executed consistently on each claim.

Mapping: Finally, the raw data must be linked together and mapped to the dimensional structure. While your managed care system manages professional, institutional, pharmacy, and dental claims differently, they can all be combined in the data warehouse to provide a complete picture of member claim costs.

Analysis leads to Insight. Once data is in the dimensional structure, powerful On-Line Analytical Processing tools can be used to find trends and seek out anomalies. For example, you may find that your out-of-network providers claim costs for a specific procedure are increasing. Further investigation points to an increase in the incidence of members seeking medical care from a set of providers in a specific sub-specialty not covered by any in-network contracts.

Making decisions to produce change. Using the insight gleaned from the above analysis, the contracts department may decide to review contracts with existing providers to include the sub-specialty getting the increased attention. Alternatively, they may decide to develop contracts with the group of physicians that are currently out-of-network and performing these specific sub-specialty services.

read more

Companies want more actionable data, and they want more users to have it. But extending the use of business intelligence throughout the organization remains a challenge. One reason: Lack of BI and IT skill sets continue to plague companies interested in taking BI to the next level, according to David Hatch, research director at Aberdeen Group.

Part of the answer lies in providing more user-friendly BI tools. Hatch offers four tips for achieving that goal.

1. Explore new user-friendly business intelligence tools. New ways of delivering BI can help in your quest to extend business intelligence throughout the enterprise. One new method to consider is BI accessed through a third party—for example, software as a service BI or on-demand BI. In addition, look into the availability of BI as an embedded capability within enterprise applications such as ERP and CRM. Since users are already familiar with your enterprise applications, they may find BI products offered through these providers easier to learn.

2. Find ways to integrate Web 2.0 information into BI. Web 2.0 data sources and other unstructured data do not obviate the need for traditional structured data, says Hatch, but they can be used to boost BI efforts. Amassing large sets of historical data reveals trends, performance metrics and specific business calculations: These are the foundation of most BI efforts. But the ability to enhance that historical data with relevant and timely information found in blogs, comments and competitors’ websites is becoming more important for delivering actionable information throughout the enterprise.

3. Give users BI tools that they can be trained to use autonomously. Employees are more likely to use and embrace business intelligence tools that they can use independently. To create an environment of business intelligence self-sufficiency, establish a group composed of both business users and IT representatives to collaborate on prioritizing user needs and choosing or developing BI tools. Hatch also advises being attuned to inflated vendor claims and involving vendors in proof-of-concept and pilot projects.

4. Consider operational business intelligence. New BI offerings that automate data collection, assembly and delivery processes are one of the most promising areas of business intelligence. To figure out if they’re right for you, look for data generated by business processes that lend themselves to automated analysis and even actions taken on the basis of that analysis. For example, some financial service organizations use applications that automatically analyze fluctuations in currency rates, and that automatically initiate trades based on those decisions. In many manufacturing organizations, data analysis is done automatically on the progress of chemical interactions—temperature, viscosity and color of a mixture, for example—and changes to the mixture are automatically made at the back end before it ever reaches people on the production line.

originally posted by Diann Daniel
read more

Ask Dennis Hernreich, COO and CFO of Casual Male Retail Group, what his life was like before he switched to an on-demand business intelligence reporting application, and he remembers the frustration all too easily.

Casual Male Retail Group, a specialty retailer of big and tall men’s apparel with $464 million in annual sales, was using a legacy on-premise reporting application for its catalog operations. (The company also has 520 retail outlets and e-commerce operations.) But the reporting features built into the system were “extremely poor,” as Hernreich describes them: “Visibility to the business? Terrible. Real-time information? Doesn’t exist. How are we doing with certain styles by size? Don’t know.”

“It was unacceptable,” Hernreich says. And viewing those “canned” BI reports (which lacked features such as exception reporting) could happen only with making a trip to the printer for a stack of printouts. “It was hundreds of pages,” he recalls. “That’s just not how you operate today.”

It’s not like Casual Male didn’t have all this information; it just didn’t have an intuitive and easy way to get at its catalog business’s sales and inventory trends in real-time. But that changed in 2004, when Casual Male began using a on-demand BI tool from vendor Oco, which takes all of Casual Male’s data, builds and maintains a data warehouse for it offsite, and creates “responsive, real-time reporting dashboards that give us and our business users information at their fingertips,” Hernreich says.

Today, Hernreich and Casual Male’s merchandise planners and buyers have access to easy-to-consume dashboards chock-full of catalog data: “What styles are selling today. How much inventory are we selling today. Where are we short. Where do we need to order. How are we selling by size. What are we out of stock in,” he says. “All of these basic questions, in terms of running the business—that’s what we’re learning every day from these reports.”

And those annoying trips to the printer have ended.

On-Demand Fears Linger
Casual Male Retail Group is part of the small (but growing) percentage of businesses using on-demand or software-as-a-service (SaaS) BI tools, which can be deployed at a much faster pace and with much less initial cost than traditional on-premise software installations.

“To go from nothing to a fully automated system in a matter of weeks is an incredible sell for any company—large or small,” says Scott Cohenford, a senior analyst at RapidAdvance, a provider of cash advances to small and midsize businesses, who led his company’s efforts to purchase Business Object’s OnDemand platform.

Note that Cohenford is not an IT person by title or pedigree (he has an accounting background): ease of use (setup, integration, training) is a major selling point to on-demand BI customers. “I was tasked with reviewing the different options out there, seeing how quickly we could move forward with the solutions and do so at a low cost and automate as much as possible,” Cohenford says. “And that’s what pushed me into the SaaS world’s BI tools.”

read more >>

continued from <<

Finding 1
The BI Learning Curve Has Just Begun
Business intelligence use grows considerably as companies gain experience with this technology. Nearly 90 percent of our respondents use BI, and most others will probably start doing so in the next two years. Still, there are relatively few BI veterans out there—companies with more than half a decade of experience using business intelligence to analyze data on customers, competitors, internal processes or financials. BI veterans use BI for more reasons and provide BI tools to staff more than BI novices do. In particular, many more veterans use BI to analyze customer data. Projecting forward, that means BI usage will grow broader—there’ll be more kinds of BI applications—and deeper within organizations in the coming years. Analysts who predict the “democratization” of BI appear correct.

Finding 2
Effectiveness Is a Sometimes Thing
BI brings benefits, but many goals go unmet. In general, IT executives are bullish on BI; nearly three-quarters say it’s doing a good job of contributing to the bottom line and pleasing users. Newcomers to BI will be glad to know the more experience companies have with BI, the happier they are with the results. But drill down to specific goals and benefits, and the track record is spotty. BI is good at analyzing financial data and internal operations. However, it’s not as effective at analyzing marketing campaigns, or cross-selling and upselling to customers. That’s a problem, especially since these are likely to be big growth areas for BI, judging by how companies with extensive BI experience use them.

Finding 3
BI Success Depends on Execution
IT organizations must focus on data management, ease of use and providing real-time information.To achieve their top business goals for BI—improving processes, sales and marketing compliance and so on—CIOs cite three priorities: improving information quality, improving management’s ability to use information, and offering more kinds of information to more people. We asked respondents how they plan to accomplish these goals. No. 1, by a longshot, is improving data management; next, in priority order are improving ease of use, improving generation of real-time information and embedding BI into business processes and workflows. These tactics should be high priorities for any IT organization implementing BI. Unless they’re achieved, companies will be hard-pressed to generate much value from the tools they use to obtain business intelligence.

Finding 4
Garbage In, Bad Intelligence Out
Good data quality and satisfaction with BI information go hand in hand. But unfortunately, many companies report data quality problems reduce the ROI on business intelligence, even after five years’ experience with these systems. CIOs who invest in establishing data quality processes will be rewarded by increased user satisfaction with the information provided by their BI systems. In addition, about half these companies have undertaken a “master data management” initiative. There’s a correlation between master data management and BI’s impact on the bottom line, but it’s not clear if it’s the result of the MDM initiative alone or other efforts to improve data quality as well.

Finding 5
Weak Links in the BI Chain
In addition to data management and quality issues, CIOs must be concerned about strategic vision, integration, usability and weak points in the BI cycle. It’s startling to see that fewer than 40 percent of companies know what they hope to achieve with BI and how they plan to use it. This sets up BI for alignment problems, such as defining BI goals, and clearly affects the contribution BI makes. Lack of integration affects more than one BI user out of three and—no surprise here—it’s especially a problem with companies in which data quality is lacking. Companies are much better at collecting and organizing data than making it usable or putting it to work. No wonder 58 percent of respondents say users don’t know how to analyze or interpret BI data.

read more here

What are the most effective ways to increase the value your company gets from its business intelligence systems?
N=215

1)Better align our business intelligence systems with our business strategy [50% ]

2)Improve data quality [47% ]

3)Better integrate our business intelligence systems with other systems such as CRM or ERP [41% ]

4)Better understand end-user needs and requirements [39%]

5)Improve user training [27 %]

Finding 1: The BI Learning Curve Has Just Begun

Finding 2: Effectiveness Is a Sometimes Thing

Finding 3: BI Success Depends on Execution

Finding 4: Garbage In, Bad Intelligence Out

Finding 5: Weak Links in the BI Chain

Next >> Finding 1: The BI Learning Curve Has Just Begun

Just 26 percent of companies using business intelligence have five or more years’ experience with the technology. Those new to BI should be encouraged by the success of those who’ve gone before.
Overall, business intelligence is an IT success story: Our most recent IT spending survey found that BI spending is increasing more quickly than spending on any other application. This month’s survey reveals that 72 percent of users say their BI efforts have had a major and measurable impact on their companies’ bottom lines. But not all business intelligence goals are being met, and there are problems beneath the veneer of satisfaction.

An overarching question in this year’s BI survey is: Are companies learning how to use BI better? The good news is that experience counts. The longer a company uses BI, the wider BI usage spreads within the organization, the more the organization tries to do with the technology and the bigger the technology’s contribution to the bottom line. That’s just what CIOs would hope to hear. This year’s survey also looks into the practices companies follow to achieve their BI goals.

We see a correlation between experience with BI, data quality and development of a clear strategy and vision for business intelligence use. Still, many long-time BI users report problems. Issues of integration, accessibility and bringing users up to speed on how to analyze and use BI data dog this technology. The value of BI increases with experience, but even veteran BI users see room for improvement, and opportunities to gain more value from BI.

read more >> Top 5 Ways To Increase BI Value

continued from here <<
“We were a very different university about one year ago,” says Keith Werosh, registrar at the National University of Health Sciences (Ill.). He is referring to the operation pre-BI. NUHS installed BI from Business Objects a year ago. “Prior to having this system, we were departmentalized. Information was kept on spreadsheets throughout the university,” he says. The Registrar would have relevant data, but not related information. “Paper touched hands a number of times. Other offices would even rekey the information,” explains Werosh. As a result, NUHS officials wouldn’t have a picture of the enrollment process until weeks into a term.

A BI solution was in order. Even so, NUHS didn’t rush into deploying one. “During a two-year time frame, we discussed what we needed and how we were going to achieve it,” adds Werosh, who was the executive on campus tapped to “get the ball rolling” because much usage would be centered around the registrar’s office.

After the investigative period, NUHS invested approximately $200,000 in a BI system supplied by Business Objects.

The benefits have been multifold. Today the registration process is clearly viewed instantly. “We can process information on the spot,” Werosh reports. NUHS can even determine the peak registration time during the day. For example, most online student traffic falls between 9 a.m. and 10 a.m. “We added additional staff at that time to handle the traffic. Student workers were added to key areas and computer labs since more online use would lead to more questions. Others worked the telephones and were able to call back immediately to those students who had contacted online, but who wanted follow-up,” he says.

Florida State University adopted BI several years earlier, according to Rick Burnett, director of student information management. “We saw data as the low-hanging fruit and wanted to start using it to figure out the best students to target.” To that end, the university, which enrolls 40,000, uses a BI system that links to its CRM system from Talisma, its databases, and other resources, to determine which classes are filling up the fastest. “An alert goes out when a course is 80 percent full.” This, in turn, affects room scheduling, and gives fodder for studying other course offerings.

BI has also added a layer of sophistication to the admissions strategy. Officials at FSU, which receives 55,000 applications each year, once had to cull through each file and hand-code information. If at the end of the decision cycle there was a change in the admissions criteria (such as the need for slightly higher GPA requirements), decision-makers would have to retouch all the files again.

Setting a BI query avoids all that. A new list of qualified applicants can be produced within 30 minutes.

read more here

A new technology can analyze data at amazing speeds. So why is higher ed slow to adopt?

Listen to higher ed futurists and you’ll be convinced that business intelligence is the wave of the future. It is the next “it” thing that will connect every part of the enterprise. Best yet, BI will link all data, allowing disparate software programs, provided by numerous and sometimes-competing vendors, to “talk” to each other.

Admissions files will connect to financial aid information will connect to student services files will connect to academic records, and so on. The end result will be data that can actually predict what that student might do next, and even calculate financial aid needs and shifting interests.

It sounds wonderful, and BI is already fulfilling its promise at some colleges and universities. Trouble is, the BI’s potential is so vast that it remains hard to get a simple understanding of it. Each vendor has its own definition of BI. Some claim that systems such as CRM (constituent/customer relationship management) and ERP (enterprise resource planning) are BI technology. Others say that data warehousing, decision support systems, online analytical processing, knowledge management, and web personalization are all part of BI.

“Everyone and their uncle is calling their solution ‘business intelligence.’ ” -Nicole Engelbert, Datamonitor
So, which is it? The answer may be a little bit of all of the above and then some.

“Everyone and their uncle is calling their solution ‘business intelligence,’ ” notes Nicole Engelbert, senior analyst, public sector technology, at Datamonitor. “Institutions are asking, ‘What does this all mean to me?’ “

Most BI systems have been around for about eight years, and most of the early adopters were in the retail sector.

Engelbert offers her own clarification. ERP, for example, provides transactional reports, she explains. “ERP will give you how many students enrolled on Tuesday, or will tell you if Organic Chemistry 101 is full.” A BI system will actually digest this information, and other data, and tell the user if Organic Chem is being offered at a good time, or if the class is losing students to the Biology 101 class offered at the same time, or if the college needs to offer additional course sections.

Comparatively, CRM systems are more about transaction and functions. They will manage recruitment campaigns, alumni appeals, and other processes. They capture the contacts of those who have visited online, and then drive the related mailing of the viewbook. But while CRM systems will certainly tally who replied and which part of the campaign delivered results, it is BI that will offer a deeper analysis. BI can predict which ZIP codes will be the most promising for a mailing, and which geographic areas will have students with the least or most need for financial aid.

Many ERP vendors in the higher education sector claim to have BI capabilities. Engelbert notes that some have formed partnerships with companies that offer true BI. Datatel’s new partnerships with Business Objects and SAS, both BI providers, are good examples. Similarly, Intelliworks, a CRM provider, has a partnership with Microstrategy.

In mid-2006, Campus Management added two BI modules, thanks to partnerships with iStrategy Solutions and Noetix. One, called CampusQuery, provides analysis at a glance. The other, CampusAnalytics, can do predictive modeling.

BI systems are most noted for their speed and convenience tools that display metrics with spotlight indicators, or dashboards. These dashboards provide quick peeks on trends in real time-and do so in a format the average user can read.

read more here

Let’s first discuss traditional database queries. In the BI environment, a BI tool or application issues a query against a database system. The query is in a formalized database language such as SQL (note that S stands for structured). A GUI may be used to hide the complexities of SQL. The results of the query can be browsed, reported on, analyzed, etc. The emphasis of this style of processing is on the analysis of structured data. It is not designed for the ad hoc browsing of information from a bunch of unrelated data sources.

Typically database query processing is formalized and standardized both in terms of the query language itself and the database structures accessed. There are natural language interfaces for doing this type of processing, but they simply convert the natural language requests into database language statements.

With database query processing you have to have some knowledge (i.e., metadata) about the structure of the data before you can access it. There has been a move to relax the structured approach of structured database processing by adding database structure and language support for accessing and analyzing semi-structured data such as XML.

When it comes to unstructured data there are two options. The first is to transform all or some of the unstructured data into a structured or semi-structured format, and store the transformed data in a database system (together with any remaining unstructured data that has not been converted). The transformed data can be associated with existing structured data in the database. This transformed data can then be processed by database queries, and any associated unstructured data retrieved as a part of the result set.

A second option for unstructured data is to access it directly using a search tool. With a search tool information is accessed using search queries. As with database languages, these queries can be generated from a GUI. The results from search queries can be browsed to find the data of interest. The search results can also be passed to an analysis tool for further processing.

Search languages are designed for accessing freeform unstructured data. Of course search queries can also access both structured and unstructured data. Search query languages are less complex than database query languages, because, unlike languages such as SQL, they are not designed for complex data retrieval and analysis.

To improve the accuracy of search queries, metadata can be extracted from the unstructured data using utilities supplied with the search tool, or by third-party vendors who offer taxonomy and information exploration tools. The better the metadata, the more accurate the search results are likely to be. The metadata adds semantic meaning to the unstructured data. In some cases, the metadata can be used to build faceted or taxonomy-driven search interfaces that use the metadata to filter the search results. The metadata can also be used to aid in the transformation of unstructured data into a semi-structured or structured format. It is these types of capability that separate enterprise search tools from internet search tools.

The bottom line is that the database query and the search query approaches are starting to come together. However, search queries are designed for the browsing of less formalized and unstructured information, whereas database queries are intended for the analysis of structured and semi-structured data. As discussed, unstructured information can be transformed into a semi-structured format, and search results can be further analyzed by analysis tools. Both approaches use some form of query language.

Originally posted by Collin White read more >>

This point is brought home by the recent announcement by Vertica of a strategic relationship with Talend, an open-source data integration vendor. Vertica markets the column-oriented Vertica Database, and has a relationship with HP and Red Hat to offer a bundled hardware and software analytical database solution. Given that Talend also has relationship with open source BI tool vendor Jaspersoft, it means the combination of Vertica, Talend, JasperSoft and Red Hat software on top of an HP hardware platform provides a cost-effective and open source data warehouse and BI environment. If this package was offered as a single solution, and supported by a single vendor, it would represent the ideal data warehouse and BI appliance solution.

In my opinion, the appliance vendors must move toward offering these types of packaged software environments if they are to survive. Simply offering better price/performance is not a viable long-term strategy. The database machine vendors discovered this. In fact, I believe the vendors need to go one step further and provide application appliances that provide a complete business solution. Although it had a proprietary architecture, the IBM AS/400 was a tremendous success because it offered a complete application solution to business users.

This is something which will help the newbee for their familiarity of Oracle apps terms.Also can be found on Oracle download site.

This combined glossary defines terms we use in the Assets, Cash Management, General Ledger, Payables, Projects, and Receivables User’s Guides and in various country-specific and region-specific manuals.

4-4-5 calendar
A depreciation calendar with 12 uneven periods: four cycles of a four-week period, followed by a four-week period, followed by a five-week period. Depreciation is usually divided by days for a 4-4-5 calendar. Since a 4-4-5 calendar has 364 days per year, it has different start and end dates for the fiscal year each year.

1099 form
The forms the Internal Revenue Service supplies to record a particular category of payment or receipt.

1099 number
The tax identification number for a supplier. According to IRS rules in the United States, lack of a valid tax identification number may result in tax withholding.
Oracle Applications stores the tax identification number for each supplier. Oracle Applications also enables you to enter a withholding status for each supplier.

1099 types
A 1099 classification scheme used in the United States for types of payments. Each 1099 form has one or more payment types. A 1099 supplier may receive payments from more than one type. The 1099-MISC form has the following types: rents, royalties, prizes and awards, federal income tax withheld, fishing boat proceeds, medical and health care payments, non-employee compensation, and substitute payments in lieu of dividends or interest.
Oracle Applications records 1099 payments by type so that you can report them according to IRS requirements.

2-way matching
The process of verifying that purchase order and invoice information matches within accepted tolerance levels. Oracle Applications uses the following criteria to verify two-way matching:
Invoice price <= Order price
Quantity billed <= Quantity ordered

24-hour format
A time format that uses a 24 hour clock instead of am and pm, so that 3:30 would be 3:30 am, 16:15 would be 4:15 pm, 19:42 would be 7:42 pm, etc.

3-way matching
The process of verifying that purchase order, invoice, and receiving information matches within accepted tolerance levels. Oracle Applications uses the following criteria to verify three-way matching:
Invoice price <= Purchase Order price
Quantity billed <= Quantity ordered
Quantity billed <= Quantity received

4-way matching
The process of verifying that purchase order, invoice, and receiving information matches within accepted tolerance levels. Oracle Applications uses the following criteria to verify four-way matching:
Invoice price <= Order price
Quantity billed <= Quantity ordered
Quantity billed <= Quantity received
Quantity billed <= Quantity accepted

Business Process Architecture (BP)
BP.010 Define Business and Process Strategy
BP.020 Catalog and Analyze Potential Changes
BP.030 Determine Data Gathering Requirements
BP.040 Develop Current Process Model
BP.050 Review Leading Practices
BP.060 Develop High-Level Process Vision
BP.070 Develop High-Level Process Design
BP.080 Develop Future Process Model
BP.090 Document Business Procedure

Business Requirements Definition (RD)
RD.010 Identify Current Financial and Operating Structure
RD.020 Conduct Current Business Baseline
RD.030 Establish Process and Mapping Summary
RD.040 Gather Business Volumes and Metrics
RD.050 Gather Business Requirements
RD.060 Determine Audit and Control Requirements
RD.070 Identify Business Availability Requirements
RD.080 Identify Reporting and Information Access Requirements

Business Requirements Mapping
BR.010 Analyze High-Level Gaps
BR.020 Prepare mapping environment
BR.030 Map Business requirements
BR.040 Map Business Data
BR.050 Conduct Integration Fit Analysis
BR.060 Create Information Model
BR.070 Create Reporting Fit Analysis
BR.080 Test Business Solutions
BR.090 Confirm Integrated Business Solutions
BR.100 Define Applications Setup
BR.110 Define security Profiles

Application and Technical Architecture (TA)
TA.010 Define Architecture Requirements and Strategy
TA.020 Identify Current Technical Architecture
TA.030 Develop Preliminary Conceptual Architecture
TA.040 Define Application Architecture
TA.050 Define System Availability Strategy
TA.060 Define Reporting and Information Access Strategy
TA.070 Revise Conceptual Architecture
TA.080 Define Application Security Architecture
TA.090 Define Application and Database Server Architecture
TA.100 Define and Propose Architecture Subsystems
TA.110 Define System Capacity Plan
TA.120 Define Platform and Network Architecture
TA.130 Define Application Deployment Plan
TA.140 Assess Performance Risks
TA.150 Define System Management Procedures

Module Design and Build (MD)
MD.010 Define Application Extension Strategy
MD.020 Define and estimate application extensions
MD.030 Define design standards
MD.040 Define Build Standards
MD.050 Create Application extensions functional design
MD.060 Design Database extensions
MD.070 Create Application extensions technical design
MD.080 Review functional and Technical designs
MD.090 Prepare Development environment
MD.100 Create Database extensions
MD.110 Create Application extension modules
MD.120 Create Installation routines

Data Conversion (CV)
CV.010 Define data conversion requirements and strategy
CV.020 Define Conversion standards
CV.030 Prepare conversion environment
CV.040 Perform conversion data mapping
CV.050 Define manual conversion procedures
CV.060 Design conversion programs
CV.070 Prepare conversion test plans
CV.080 Develop conversion programs
CV.090 Perform conversion unit tests
CV.100 Perform conversion business objects
CV.110 Perform conversion validation tests
CV.120 Install conversion programs
CV.130 Convert and verify data

Documentation (DO)
DO.010 Define documentation requirements and strategy
DO.020 Define Documentation standards and procedures
DO.030 Prepare glossary
DO.040 Prepare documentation environment
DO.050 Produce documentation prototypes and templates
DO.060 Publish user reference manual
DO.070 Publish user guide
DO.080 Publish technical reference manual
DO.090 Publish system management guide

Business System Testing (TE)
TE.010 Define testing requirements and strategy
TE.020 Develop unit test script
TE.030 Develop link test script
TE.040 Develop system test script
TE.050 Develop systems integration test script
TE.060 Prepare testing environments
TE.070 Perform unit test
TE.080 Perform link test
TE.090 perform installation test
TE.100 Prepare key users for testing
TE.110 Perform system test
TE.120 Perform systems integration test
TE.130 Perform Acceptance test

PERFORMACE TESTING(PT)
PT.010 - Define Performance Testing Strategy
PT.020 - Identify Performance Test Scenarios
PT.030 - Identify Performance Test Transaction
PT.040 - Create Performance Test Scripts
PT.050 - Design Performance Test Transaction Programs
PT.060 - Design Performance Test Data
PT.070 - Design Test Database Load Programs
PT.080 - Create Performance Test TransactionPrograms
PT.090 - Create Test Database Load Programs
PT.100 - Construct Performance Test Database
PT.110 - Prepare Performance Test Environment
PT.120 - Execute Performance Test

Adoption and Learning (AP)
AP.010 - Define Executive Project Strategy
AP.020 - Conduct Initial Project Team Orientation
AP.030 - Develop Project Team Learning Plan
AP.040 - Prepare Project Team Learning Environment
AP.050 - Conduct Project Team Learning Events
AP.060 - Develop Business Unit Managers’Readiness Plan
AP.070 - Develop Project Readiness Roadmap
AP.080 - Develop and Execute CommunicationCampaign
AP.090 - Develop Managers’ Readiness Plan
AP.100 - Identify Business Process Impact onOrganization
AP.110 - Align Human Performance SupportSystems
AP.120 - Align Information Technology Groups
AP.130 - Conduct User Learning Needs Analysis
AP.140 - Develop User Learning Plan
AP.150 - Develop User Learningware
AP.160 - Prepare User Learning Environment
AP.170 - Conduct User Learning Events
AP.180 - Conduct Effectiveness Assessment

Production Migration (PM)
PM.010 - Define Transition Strategy
PM.020 - Design Production Support Infrastructure
PM.030 - Develop Transition and Contingency Plan
PM.040 - Prepare Production Environment
PM.050 - Set Up Applications
PM.060 - Implement Production Support Infrastructure
PM.070 - Verify Production Readiness
PM.080 - Begin Production
PM.090 - Measure System Performance
PM.100 - Maintain System
PM.110 - Refine Production System
PM.120 - Decommission Former Systems
PM.130 - Propose Future Business Direction
PM.140 - Propose Future Technical Direction

Over the last few issues of this newsletter, I have been writing about the impact of Enterprise 2.0 approaches on business intelligence (BI). I intended this time to write about how business intelligence and data warehousing can exploit the growing amount of business content generated by Enterprise 2.0 collaborative and social networking technologies. I decided, however, that before I could do this, I first needed to review the role of data warehousing in BI projects; because as companies move toward using new BI approaches (operational BI, for example), this role is changing.

The title of this article is deliberately provocative. My objective is to encourage business intelligence professionals to consider the role of data warehousing in new BI projects. In the past, data warehousing has been the cornerstone for such projects; but I believe that in many situations, this is no longer true.

A Historical Perspective
Essentially, there are three main types of IT processing involved in running the business: business transaction processing, business intelligence processing and business collaboration processing. Business transaction applications run day-to-day business operations, while BI applications analyze those operations with the objective of optimizing and improving them. Collaboration systems enable business users to share information and expertise about business operations.

Prior to the introduction of the concept of business intelligence, most companies analyzed their business operations using decision support applications that queried and reported directly on data stored in business transaction databases. There were several problems with this approach. The five key ones are: 1) the data was not usually in a suitable form for reporting, 2) the data often had quality issues, 3) decision support processing degraded business transaction performance, 4) data was often dispersed across many different systems, and 5) there was a general lack of historical information.

Data warehousing was introduced to help solve these data and performance issues. While there is no question that data warehousing helped improve business decision making, it is important to realize, nevertheless, that it was introduced primarily to solve design issues in business transaction systems, and also for performance reasons.

The emergence of business intelligence and business performance management (BPM) applications and tools further enhanced business decision making by giving business users simpler interfaces, improved data analysis features, and the ability to compare actual and planned performance. Although business intelligence and business performance management applications typically process data in a data warehouse, this is only because of the five issues outlined earlier concerning direct access to business transaction data. If these issues could be resolved, then there would be no need for a data warehouse.

Traditional Business Intelligence
Traditionally, business intelligence has been used for many years for strategic and tactical decision making. This type of processing involves intensive analytical processing of historical and summarized data managed in an enterprise data warehouse. Data performance issues caused by centralizing data in an enterprise data warehouse have led to the creation of data marts, which solve performance problems by spreading the BI processing across multiple data stores.

The problem with data marts is that organizations often build them directly from business transaction databases, rather than the enterprise data warehouse. This is because it is often quicker and easier to build a data mart than to incorporate additional data into the enterprise data warehouse and then build the data mart from the data warehouse. Another problem is that many organizations have more than one “enterprise” data warehouse. Multiple disconnected data warehouses and data marts leads to data consistency issues, which data warehousing was supposed to solve in the first place.

There are many articles written about the problems of building dozens of independent data marts directly from operational data, and I will not discuss these problems here. It is worth pointing out, however, that a data mart solves most of the same issues addressed by an enterprise data warehouse with the exception that decisions sourced from multiple data marts may be inconsistent in the same way that decisions based on multiple business transaction databases can be inconsistent. This multisource issue could be mitigated by first integrating the business transaction data, for example, into an operational data store or master data store. The issue of historical data would have to be addressed, but this is solvable.

Historical Data and Current Data
The distinction between current data and historical data should be easy to define, but it is not. Data in a business transaction data store is usually current, while data in a data warehouse is usually considered to be historical. The issue here is, “What is meant by current and historical?” Let’s look at an example.

If I have multiple telephone accounts with a telephone company, then (in simplistic terms) the company will have a record showing my customer data, and a record for each of my accounts listing the telephone number, account balance, billing data and so forth. When I make a telephone call, send a text message or access the Internet, I create a call data record (CDR) that can be collected with other CDRs to analyze customer calling patterns, detect fraud, etc.

At any given moment in time, the customer and account records will show the latest information about my current status. This can be considered to be current data. As this data is updated with new address and account data, the old data may be captured into a data warehouse for analysis purposes. The capturing process may be done at particular moments in a time (a snapshot), or continuously, depending on how the data will be analyzed. Regardless, the data in the data warehouse is historical.

The CDR data is a different situation. In general, once I make a phone call, the CDR for that call never changes. When a telephone company captures the CDR into a data store for analysis, is the data current or historical data? The answer is it is current data because even though the data ages over time, it is always the current version of the data. What name do we give the CDR data store? I suspect most people would call it a data mart. Is this the correct term? Does it really matter what we call it, other than the fact some people have the need to give things labels? Regardless, we most probably don’t want to keep the CDR data in an enterprise data warehouse. It is useful, however, to keep a historical record of the CDR analysis results because this shows trends and patterns over time.

If the CDR information is used to detect fraud, then the quicker the analysis can be done, the faster fraud can be detected. The business intelligence application can process the data in-flight as it flows through the system, or can analyze it in a persistent data store that is updated continuously with the CDR data. Data mining of past CDR records can help set up the business rules for doing this detection. This fraud detection application is a good example of an operational BI application.

Operational Business Intelligence
There are a growing number of operational business applications similar to those described previously for CDR analysis. The business benefit of these applications is that they can help companies become more agile by analyzing data during intra-day operations. The ultimate example of this type of processing is algorithmic trading, which employs complex event processing (CEP) and stream analytics to optimize trading operations. The response time of these analyses are a fraction of a second. In this type of processing, it is not feasible, or even necessary, to store the huge volumes of data involved in a data warehouse. The results of BI processing, however, may be kept for future use.

The model for many operational business intelligence applications is capture data, analyze data, persist results (i.e., they analyze data before persisting it). This is different from the traditional BI model of capture data, persist data, analyze data, persist results. BI applications that analyze Web traffic and business activity on commercial websites to track buying trends, optimize prices, and so forth is another example of operational BI. Although these applications analyze data in-flight, they may also use historical data in a data warehouse to assist in the analysis.

Why is this discussion important? The main reason is at present, business intelligence is synonymous with data warehousing. This thinking is wrong and needs to be changed. Data warehousing is a component of business intelligence, but business intelligence may employ data in other data stores. In some cases, a BI application may not even use data managed in a data warehouse. The tight connection between business intelligence and data warehousing is causing terms such as virtual data warehousing and virtual BI to be used to describe other types of BI processing. These terms are unnecessary and just confuse everybody.

Another issue is that people have forgotten that data warehousing was created to overcome deficiencies in business transaction systems. Many of these issues are now solvable. My concern is that data warehousing has become a system in its own right and that companies are now extending the data warehouse into other application areas such as master data management and content management. This is completely the wrong direction and must be argued against.

The bottom line is that data warehousing is still an important component of business intelligence, but it is no longer the foundation on which all BI projects have to be built.

original article by Colin White

>>read more>> here

some of the questions and answers listed here might repeat .from

http://www.infopurple.com/interview-questions-oracle-ar-functional-accounts-receivables-02

http://www.infopurple.com/interview-questions-oracle-ar-functional-accounts-receivables-01

1. How do you create a Chargeback Invoice ?
A. Using Receipts window

2. How do you adjust the amount of advance already received against an Invoice ?
A. Create an Invoice for Deposit and receive an amount against this deposit Invoice. Then Create the regular invoice and in the column of Commitments enter the number of Deposit Invoice. The Regular Invoice gets matched with the Deposit Invoice for the amount of Regular invoice or deposit invoice which ever is lower

3. How do you write off small amounts while accounting the receipt against an invoice?
A. Using Receipts window. You have the button for write offs.

4. How do you Account for bank charges deducted from amount received against an invoice?
A. Using Quick cash window also you can enter receipts. Here you have the option of accounting the bank charges deducted on receipt. However, this has to be enabled by putting the Value in profile option AR: Create Bank Charges = YES.

5. How do you create a credit note against an invoice ?
A