There are a number of ways to get the Month Name for a date to display in your report.  Only one method gives you the Month Name and sorts properly (in calendar month order). Other methods, such as using the MONTHNAME function will return the name of the month, but will sort alphabetically rather that in calendar order.

The first step is to use the MONTH function to return the Month Number for the dates. Shown below is a report that contains Close Month, Close Date, and Opportunity Name. Close Month is calculated with the formula: MONTH(Opportunity."Close Date")

The next step is to modify the Data Format of this Close Month column. Override the default data format on the Data Format tab of the Column Properties window. You can select either Month Name or Month Name (Abbreviated). This displays the number as the month name, but does not change the data in the column to another data type. In other words, the report still contains the numbers, but they are masked as month names. This way, they sort numerically and stay in calendar order.

Using this method, displaying data in timeline order with month names becomes very easy.

Release 19 of Oracle CRM On Demand is in the process of rolling out, and there are some great new features coming with it. Perhaps you have heard some of the highlights, but have you considered what you will be able to do with these new capabilities?

Enhanced Mobility
Release 19 adds the Safari browser on the iPad OS to the supported browsers list. That means users can access, and do most things in CRM On Demand using their internet-connected iPad. If your company has not yet issued you an iPad, your case to procurement gets a little stronger once Release 19 goes live. Your mobile sales force will be able to access CRM On Demand on the road using their iPads. Aside from the obvious convenience factor, expect to see some high user adoption and an increase in cool points when you show up at the client site working with the latest technology. For single-tenant customers (for now) Release 19 comes with the ability to deeply integrate with Microsoft Outlook. This integration, called CRM Desktop, allows users to access their contacts, accounts, opportunities and more through the very familiar Outlook interface. Working online or offline with bi-directional sync, users can quickly work with their CRM data within Outlook without accessing another application. Multi-tenant support is planned for the future.

Operational Analytics
So you invested in CRM On Demand, configured the application, loaded up your data, built some reports, and trained your users. So, how is the system running? What pages are the users using the most? Which dashboards and reports are getting the most usage? Are the reports responding quickly? If you are not using Release 19 yet, you probably do not have good answers to these questions, but you can soon! With Release 19 the Usage Tracking Analysis subject area in Analytics is expanded to allow for analysis of page and report requests and response times so you can see who is doing what and how well the system is supporting their usage. It may sound a little “big-brotherish” but consider that you will be able to proactively identify areas of the system that are not being used, or individuals who might need some additional training, and solve a problem before it becomes a problem, and big brother doesn’t seem like such a bad guy.

Exchange Rate API
If your company is working with multiple currencies, right now your administrator must manually update the exchange rates table each month. With Release 19 the Exchange Rate will be accessible through Web Services using the Exchange Rate API. This means that integrations will become possible that enable an automatic update to the Exchange Rate table in CRM On Demand using rates fed in from other systems. No more worries about having different rates in different systems across the enterprise, and no more manual updates to the exchange rates table which are subject to human error and rely on the right person being at work the day the exchange rates are supposed to be updated.

File Hosting
Right now, if you wanted to display an image, HTML page, or a flash presentation within CRM On Demand, you would have to host those files somewhere on the Internet and hope that the browser setting of your users allow for the display of data from multiple hosts. With Release 19, you will be able to upload five different file types to the CRM On Demand server. Images in GIF or JPG format, Flash (SWF) files, and HTML and CSS files are permissible and once uploaded will be assigned a URL that you can embed into Web Applets, Web tabs, and reports.

Opportunity Hierarchy
Release 19 introduces sub-opportunities. This could be a game changer if your company has larger, multi-faceted opportunities. Many companies are realizing that their sales opportunities are not simple product purchases, but actually involve multiple stages, or a mixture of products and services, or involve multiple sales people or teams… in short, opportunities are more like projects. So with release 19, the concept of parent-child relationships between opportunities is introduced. A parent opportunity can have multiple child opportunities associated with it. Each opportunity is managed separately as an individual opportunity, and you can report on opportunities individually or the entire opportunity hierarchy rolling the revenue up.

User Interface Enhancements
With every release there is a plethora of small, seemingly insignificant, enhancements that make the application easier to use, provide a more pleasant user experience, speed up performance, or address a small gap in functionality. These are not big changes that get pages of documentation or demand much time in the spotlight during the release slide shows. They are, however, improvements that can impact your business and how you use CRM On Demand.

Lists in CRM On Demand are enhanced in a couple of ways with Release 19. The activity default lists have been modified for better performance by tweaking the filters a bit to be more efficient. The Activity tables are usually the fastest growing tables in your database, and the more efficient the lists, the better, as that record count increases. Speaking of record counts, in Release 19 you will be able to click the Edit button on your list results and select Record Count to see exactly how many records are in your list results. No more paging through the list tallying the records. Oh, and the paging buttons have changed a little too and are positioned in the top right of the list results so you do not need to scroll to the bottom to move to the next page.

Another rather simple change involves the Action Bar. The ever-present Action Bar on the left side of your CRM On Demand screen takes up a good bit of screen real estate. With Release 19, you can grab the right side of the Action Bar and slide it off the left side of the screen and bring it back when you need it. That frees up more space on the screen for your lists, reports, and data entry. Dynamic layouts have been around for several releases now. They allow you to dynamically show layouts based on the type field on a record or on a user’s role. This enables a more focused user experience for different types of users and different types of records while working with CRM On Demand. With release 19 this functionality becomes available on the Custom Objects. This means that your custom objects can dynamically change their appearance just like the other objects in the application.

All in all some pretty nice advances, with more to come in some minor releases scheduled for later in the year.

Written by:
Doug Cummings,Vice President of CRM Practice Development
Mike Lairson,Manager of Business Intelligence Services

The purpose of Oracle Approvals Management (AME) is to define approval rules that determine the approval processes for a specific Oracle applications product such as Oracle Self Service or Oracle Purchasing or for that matter Oracle iExpense.

An approval rule is a business rule that helps determine a transaction's approval process. Rules are constructed from conditions and actions. If any only if those rules conditions are met transaction should go through the system.

For example an approval rule can be as follows: If the transaction's total cost is less than 1,000 USD, and the transaction is for travel expenses, then get approvals from the immediate supervisor of the person submitting the transaction.

The approval rule's if part consists of zero or more conditions, and its then part consists of one or more actions. A condition consists of a business variable (in AME, an attribute) and a set of attribute values, any one of which makes the condition true. An action tells AME to modify a transaction's approval process in some fashion. The Conditions in the sample rule in the graphic refer to two attributes: the transaction's total cost, and the transaction's purpose. The sample rule's action tells AME to add the requestor's supervisor to the transaction's approver list.

AME enables you to define rules that express a wide variety of approval rules. For example, rules that: • Require subject-matter-expert approval • Require managerial approval • Create exceptions for rules requiring managerial approval • Substitute one approver for another in special cases • Revoke a manager's signing authority in special cases • Grant a manager extra signing authority in special cases • Generate a production that assigns a value to a variable name such as the value • Send for-your-information notifications.

You can prioritize the approval rules. This enables you to apply rules of sufficient priority to any given transaction. There are much more capabilities a business user can achieve and the amazing part is, it is really simple to achieve via AME.

So, what is user adoption?  The answer is multi-faceted, so let’s begin with a simple definition.    Pure and simple, user adoption conveys acceptance of something.  Well, that does sound pretty simple, doesn’t it?  If I accept that a new software system is in place at my company, that means I actively use it, right?  Wrong.  As adults, we can easily accept something, but that doesn’t mean we use it for the long haul.  Why is that?  Let me back track here with a little close-to-home story, which I believe will resonate with many of you.

I have my own user adoption experiment going on right here under my roof, in the form of three children, who must be taught to brush their teeth every morning and every night.  Wait a minute!  I thought this was a story about software adoption?!  It is – underlying the adoption of anything is a change in the behavior required to attain true adoption.  So how did I get my children to adopt teeth brushing as part of their daily routine, and take true ownership of the task?  Did I entice them with the promise of a beautiful smile?  Did I forebode a mouth fraught with cavities?  Sure, I tried both of these angles.  And no surprise, these sticks and carrots fell on deaf ears.  The allure of something shiny, or the threat of something punitive, does little to motivate human nature.  What I really needed in this situation was some good ol’ behavior modification.  So up the stairs I march them, day in and day out, with the same refrain each time, “guys, it’s time to go brush.”  I make sure we accomplish this task, every morning, and every evening.   It is part of our routine; I have fostered the behavior required to make teeth brushing something we just do, and my kids accept it so much so that the new normal around here, when I announce that it’s time to brush, is the delightful reply “we already did.”  I confirm a job well done, and bask in some small amount of pride that I’ve fostered the behavior that has lead to this adoption.

In my anecdote, the teeth brushers are the end users, I their manager.  And what this story illustrates, beyond the requests for new toothpaste flavors, cool toothbrushes and, please, don’t brush so hard, is how we get people to adopt something.  What any organization must do, with the manager playing in the starring role, is make a valuable process part of a routine.  By facilitating this routine, typically vis-à-vis team meetings, one-on-one coaching sessions, report running, etc., the manager sets the stage for this thing (in our case, software) to become part of the new normal.  That’s right, I’m talking about managers engaging their folks on a routine basis to use the software, refer to it for business insight, and trust it to make key business decisions.  This human involvement in behavior modification is a must – there is no substitute for one person to model for another the value of a software tool, and turn that process into a daily routine that is continually monitored and encouraged.  In short, user adoption is not an event, it’s an on-going, manager sustained process of supporting the behavior that underlies immediate and on-going adoption.

So I leave you with this question: Is user adoption really that simple?  It can be.  It requires insight, lots of human interaction (managers, I’m talking to you) and continuous commitment and oversight to the process.  If I haven’t made a believer out of you yet, just go ask your mom how she got you to adopt brushing your teeth – now off you go!

I think it is high time we started blaming our Math teachers, or more specifically, our childhood school systems for teaching us computation rather than math. We sat through countless hours of algebra, calculus, physics, and statistics classes and we wasted a lot of time hand solving quadratic equations and the like. When is the last time you needed to break out a sheet of paper and hand solve a complex calculation?

Today, we have machines that perform calculations thousands of times faster and with more accuracy than the fastest of humans - and most of us are pretty darn slow when it comes to calculating. So if we have computers, and analytics applications that do all these things so well, why is business intelligence so difficult? The key has to do with the portion of your math classes that were not taught because it was not part of the curriculum or perhaps because the teacher did not understand it all that well either.

I recently watched a TED talk given by Conrad Wolfram, the man behind Wolfram Research, who described a math in four parts:
1. Posing the right question
2. Translating from a real world question to a formulation
3. Computation
4. Translating back to a real world solution

If we consider the 80/20 rule here, we can argue that 80% of our time in math classes was spent on calculation and the other 20% might have touched on the rest in the form of word problems where all of the necessary data is spelled out pretty clearly. Unfortunately, life is more like the inverse. We spend 80% of our time trying to figure out the question and translate that question into some sort of calculation and back into a solution to the problem. We only spend 20% of our time doing any computation, and that is usually trying to determine if the larger or smaller package is the better deal in the grocery store.

This is the same paradigm we find ourselves trapped in when we look at implementing business intelligence tools. The tool does a lot of the work for us - it calculates and draws the charts and does it all very quickly and accurately, given that we provide the correct data. Automation allows for separation of the calculating from the problem. Where the real work lies is in the identification of the business question and turning that business question into a reporting requirement and then translating the resulting report into some answer or action. These are the exact skills we were not taught during our math classes. This mathematical reasoning is a skill that many of us have to develop on our own, in spite of our mathematical education.

Albert Einstein, who is said to have known a thing or two about math, said that “the formulation of a problem is often more essential than its solution, which may be merely a matter of mathematical or experimental skill.”

When I teach report building workshops, I always begin with a module on defining the business question and challenge the participants to always identify the business need for a report before building it. The building of reports is merely a matter of skill in identifying the data sources and filtering data. The formulation of the question and justification for the report and translation of the same into a report specification is the hard part - the part we have not been well trained to do. Our schooling has left us with not enough mathematical initiative and a bitter aversion to word problems. The logic behind the formulas mattered less than the ability to perform the calculations necessary to solve the formula.

Take the example of the Sudoku puzzle. If 80% of the blanks are filled in for you, the last 20% takes very little effort to complete. However, if only 20% of the blanks are filled the puzzle is much more difficult to solve. The data is simple - we know which numbers to use. The layout is predetermined - we know how many squares there are and how they are arranged. The complexity of the logic is the difficult part. This is not unlike business intelligence. Creating a report with a simple table and a chart is easy - just a set of button clicks, really. Understanding the logic behind the report - why are we using this data - how does this data relate to that data - what are we going to do with this information - these are the tricky parts. Anyone can build a report that looks good, but it takes more than button clicks to build a report that answers a real business question and serves a real purpose.

In addition to taking this opportunity to lash out at my past math instructors, the point I want to make is this: When considering a business intelligence solution for your company, many tools will provide the computation components that you need. Selecting a tool is the easy part - the familiar 20%. The hard part is identifying the team of people that are best suited to handle the other 80%. Seek out people who know the business well, are familiar with the challenges and can translate those challenges into business questions. In short, look for people who love a good word problem, cannot stand to leave a puzzle unfinished, and can describe something complex in simple terms.

What is the difference between Product Data Management (PDM) and Product Lifecycle Management (PLM)?  These two acronyms do cause a lot of confusion – to some they are synonymous, to others the distinction is about scale, and to others there is a strict delineation in the processes supported by each and their target user base. 

What is important is not to get hung up on the names, but to focus on the business processes a solution is addressing.  Oracle’s Agile PLM system takes a module based approach that supports all business processes typically associated with PDM/PLM and then some.  It all centers around the core foundation of the ‘Product Collaboration’ module.  Here you can manage items, BOMs, ECOs, approved manufacturers, and all associated files and documents.  From there the Engineering Collaboration module allows seamless access and integration to/from engineering design tools, while the Product Sourcing, Product Compliance, and Product Quality modules extend into the supply chain and manufacturing process.

At the end of the day, the goal is to have a single view and repository of product related data that the entire organization utilizes and respects as ‘the place’ to go for product information – and to be wary of point/limited scope solutions that create information islands that need to be continually reconciled.