Forrester report on Fusion: What about the Technology adoption curve?

Research and advisory firm Forrester published a report last week claiming that Oracle's Fusion strategy was not working. You can catch excerpts of the report here. The report which surveyed around
114 Applications Unlimited customers (PeopleSoft, E-business suite, JD Edwards, Siebel etc) claimed
that majority of them have no plans of moving to Fusion. The report claimed that customers are satisfied with Applications Unlimited products and are not enticed enough to migrate to Fusion, thereby representing a strategic dilemna for Oracle. The conclusions made by the report as well as by certain analysts who used the report to criticise the customer adoption rate of Oracle Fusion Applications, came across as flawed to me.
An important conclusion of the report is that Fusion is not seeing a high level of adoption in the market, especially amongst Applications Unlimited customers. This analysis is made on the premise that two-thirds of the survey respondents reported that they do not have plans to migrate to Fusion (the question posed was 'Does your organisation have plans to implement Oracle Fusion apps). An implicit assumption behind this conclusion is - 'a majority of existing PeopleSoft/E-business suite/JD Edwards customers would have moved to Fusion as soon as the product released'. The survey numbers did show that a majority of Applications Unlimited customers in the list of respondents had not moved to Fusion (nor had plans to move to Fusion) and concluded that as a strategic issue for Oracle! (I strongly recommend reading this post on the Constellation Research blog on why Applications Unlimited strategy was important for Oracle when it was launched in 2006). A lot of analysis made on this topic revolves around the above stated assumption that customers should have snapped up Fusion Applications soon after it's launch - unfortunately this assumption is in contradiction to the pattern in which technology is adopted by society. To understand the adoption rate reported for Fusion applications, I think it is pertinent for us to look at the standard models of technology adoption.

The process of adoption over time is typically illustrated as a classical normal distribution or "bell curve." The model indicates that the first group of people to use a new product is called "innovators," followed by "early adopters." Next come the early and late majority, and the last group to eventually adopt a product are called "laggards". Thus, technology adoption follows a bell curve with a critical initial period when the product gains acceptance in the market and crosses the 'chasm' (courtesy Geoffrey Moore and his best selling book, Crossing the Chasm) from early adopter customers to a critical mass of early majority customers. Why should the adoption pattern of Fusion be any different, especially when the customers are risk averse large scale enterprises? Thus, the assumption that majority of Applications Unlimited customers should have moved to Fusion Applications as soon as the product was launched is a flawed one - the market just doesn't behave that way (and we need to consider that each market segment has its own pace of adoption). Fusion is at present in the 'early adopters' phase and I am sure that it will take another 2 to 3 years, before it can pull in the early majority crowd. Fusion Applications have only been available from 2011 and already counts 100+ live customers. How does this fare with the adoption rate of Workday? As reported here, Workday which was launched in 2005, reached the 50 customer mark only in 2008. I acknowledge the bias in this comparison as Oracle already has a large install base in comparison to Workday, but I believe it goes on to represent that technology adoption goes through a critical initial phase, before the product gains a self sustaining critical mass of customers. If the commentators were to take into account the above facts, probably the conclusions made out of the survey would have been vastly different.

Cleaning up AWE entries for Absence Management and Time and Labor

This post is a response to a query that was raised in ITToolbox today. The query concerned a need to delete entries created by the Absence Management AWE (Approval Workflow Engine) process definitions. We have seen this requirements being raised at a number of customer sites, where it is needed to cleanup 'orphaned' AWE entries. Orphaned AWE entries are those transactions that are present in the AWE specific workflow tables, but not having the actual transactional data in core absence management tables.
So, here is the list of tables that need to be cleaned up, if ever this requirement arises:

1. GP_ABS_SS_DAT
2. GP_ABS_SS_STA
3. GP_ABSSS_V_XREF
4. EOAW_USERINST
5. EOAW_STEPINST

If the above requirement arises for Time and Labor, the following list of impacted tables need to be cleaned up:

Reported Time Approval:

1. TL_APP_HDR
2. TL_APP_RPT_LINE
3. TL_APP_RPTD_XRF
4. EOAW_USERINST
5. EOAW_STEPINST

Payable Time Approval;

1. TL_APP_PAY_HDR
2. TL_APP_PAY_LINE
3. TL_APP_PAY_XRF
4. EOAW_USERINST
5. EOAW_STEPINST

Note that this post only lists the tables involved in the AWE processes of PeopleSoft Absence Management and Time and Labor. Ensure that correct SQL scripts are written and tested, prior to executing the actual cleanup. If necessary, consult support.oracle.com where there is good amount of documentation on this subject, as well as sample delete scripts.