Oracle is going to make life easy for the PeopleTools product managers if they keep acquiring all of the 3rd party products that PeopleTools embeds :-)

Joking aside, an Oracle acquisition of BEA would mostly be a non-event for PeopleSoft customers. Sure, there's potential for some of BEA's middleware to become of the Fusion stack down the road, but purely for the purposes of running current PeopleSoft applications, nothing would be likely to change (except for the logos on the installers!).

As was the case with Crystal and other 3rd party products that PeopleSoft used, there were long term contracts in place for Tuxedo and WebLogic. These contracts always included language that dealt with acquisition scenarios, including scenarios where the acquirer was hostile to PeopleSoft. Fairly standard stuff in terms of protecting yourself from the unexpected (or maybe these days you'd call it the expected).

Of course, even long term contracts do come to an end. Since Oracle is going to support PeopleSoft for some lengthy period of time, how to handle 3rd party products over the long haul still is an interesting question. When a contract comes up for renewal, there's always the chance that negotiations won't go well. As a product manager, you always have to have a backup plan ready in case you suddenly need a replacement.

I had an interesting lesson in this one time when my boss at the time, Peter Gassner, drug me and Tressa Novak, who ran the Business Development group for PeopleTools, into an extraordinarily long meeting with a vendor that believed that they had PeopleSoft over a barrel at contract renegotiation time. I won't mention their name (but I will tell you that they haven't been mentioned at all on this blog), but they brought in a few high level folks that had barely contained smiles on their faces. The anticipation of a giant payday must have been pretty strong.

The next few hours were spent with Peter slowly, but surely, convincing them of exactly how PeopleSoft could move away from being dependent on them, what the effort would take, what the problems would be and how they would be dealt with, etc. It was interesting to watch their smiles very slowly turn into frowns as they realized that they didn't have quite the leverage that they thought they did. They left the meeting room without the smiles, but still as a PeopleSoft partner. Without the detailed backup plan in place, then the negotiations surely would have turned out much differently (probably with them making Sales Club for the next few years!)

It would have been pretty funny if we had just said that we were going to buy them instead :-)

As for backup plans for WebLogic and Tuxedo, those are taken care of as well. Replacing WebLogic if absolutely necessary would be easy to do since Oracle's own J2EE server as well as IBM WebSphere are already supported choices.

Tuxedo would definitely be a harder effort, but PeopleSoft actually doesn't leverage Tuxedo so deeply that it wouldn't be possible. In fact, most of what PeopleSoft gets from Tuxedo is also supplied by leading J2EE containers these days. The bigger headache is that the PeopleTools code that runs as Tuxedo services is written in C++. Using JNI to make that work inside of a J2EE container wouldn't be pretty, but PeopleTools already uses JNI extensively for all of the Java/PeopleCode integration. Not a pretty solution, but as a backup plan, it's manageable. Certainly more so than porting all of the PeopleTools C++ code to Java, which was bandied about on a few different occasions.

Labels: 2007, Business, History

Well, I guess that I should have done a little more testing prior to publishing last night's posting. In order to figure out what pages and components to look at when adding my code, I opened them up and used PSIDE helper to drill into the definitions.

Unfortunately, I didn't realize that there were global variables that drove the logic on the pages that I was working with (and those vairables prevented me from finding a couple of design flaws in my approach).

Well, I discovered the error of my ways and realized that I needed to move one component back in the chain with my entry-point (which meant that I needed to add code to two pages instead of one). Try the code on the posting now.

Labels: Drilling, HCM, User

I've recently been spending a bit of time working in HR on a Co-Presentation with Business Objects for their upcoming conference this week. One of the things I wanted to show was how to open up a performance review or a development plan from a report. Unfortunately, the pages in HCM don't allow you to pass in an EMPLID or a Review Type to open it up.

The Solution

The solution is similar in nature to what I did for navigating to values in the Journal Entry page. I used the %Request.GetParameter() function to allow the URL to navigate to the page to contain the extra parameters I needed. I then used the parameters to find the document I wanted to open, and opened it. I ended up need needing to add code to two different locations to make it work (mainly because the performance documents were written as several different components that transfer the user around):

• The first was to add Page.Activate PeopleCode to the EP_LAUNCH page. This code accepts the parameters passed on the URL. Because those parameters will be lost after a transfer event, it puts them into global variables to be used later.
• The second is to modify the Page.Activate PeopleCode of the EP_APPR_SELECT page to use the parameters passed on the command line to walk through the list of documents and open the appropriate one.

In case you were wondering what the navigation would look like, here are a couple of URLS that would open up the appropriate documents.

The first is a URL to open an annual performance document (for employee KU0065): http://www.gsdemo.com/psp/ps/EMPLOYEE/HRMS/c/ROLE_MANAGER.EP_CURRENT_MY_PRF.GBL?&PAGE=EP_APPR_SELECT&EMPLID=KU0065&EP_REVIEW_TYPE=K0ANNUAL

The second URL opens up a development document (for employee KU0119): http://www.gsdemo.com/psp/ps/EMPLOYEE/HRMS/c/ROLE_MANAGER.EP_CURRENT_MY_DVL.GBL?&PAGE=EP_APPR_SELECT&EMPLID=KU0119

Here's the code needed on the Page.Activate program within the EP_LAUNCH page:

Because this page doesn't already have PeopleCode here, you can simply copy and paste the following code(tested against HCM 8.9).

/* ********************************************************** */
/* Grey Sparling - Add Code to Open up an item passed on URL */
/* ********************************************************** */

rem Grey Sparling - Retrieve Parameters to open up employee;
Global string &gsEmplID;
Global string &gsRevType;

&gsEmplID = RTrim(%Request.GetParameter("EMPLID"));
&gsRevType = RTrim(%Request.GetParameter("EP_REVIEW_TYPE"));

Here's the code needed on the Page.Activate program within the EP_APPR_SELECT page:

The first step is to declare the global variables near the top of the program. It already contains the declaration for &EP_GBLKEYS_WRK. You should put the following lines above it.

/* Grey Sparling - Declare Globals */
Global string &gsEmplID;
Global string &gsRevType;

The rest of the code should be appended to the end of the page activate peoplecode on the EP_APPR_SELECT page.

/* ********************************************************** */
/* Grey Sparling - Add Code to Open up an item passed on URL */
/* ********************************************************** */

If None(&gsEmplID) Then


&gsEmplID = RTrim(%Request.GetParameter("EMPLID"));

End-If;
If None(&gsRevType) Then

&gsRevType = RTrim(%Request.GetParameter("EP_REVIEW_TYPE"));

End-If;

rem Grey Sparling - If EMPLID is passed, walk through the rowset to find it;
If All(&gsEmplID) Then

Local Rowset &rsEPApprSelect = GetLevel0().GetRow(1).GetRowset(Scroll.EP_APPR_SEL_VW);

Local number &j;
For &j = 1 To &rsEPApprSelect.ActiveRowCount


Local Row &rowTest = &rsEPApprSelect.GetRow(&j);

rem Grey Sparling - Test passed in parameter against current row's emplid;
If &rowTest.GetRecord(Record.EP_APPR_SEL_VW).GetField(Field.EMPLID).Value = &gsEmplID Then

Local string &rsRevType = RTrim(&rowTest.GetRecord(Record.EP_APPR_SEL_VW).GetField(Field.EP_REVIEW_TYPE).Value);

rem Grey Sparling - If there's no reivew type parameter or if there is and parameter matches for current row, open up document;
If None(&gsRevType) Or

&rsRevType = &gsRevType Then

/* Transfer the user to the selected review sub-document */
&EP_GBLKEYS_WRK.EMPLID.Value = &rowTest.GetRecord(Record.EP_APPR_SEL_VW).GetField(Field.EMPLID).Value;
&EP_GBLKEYS_WRK.EP_APPRAISAL_ID.Value = &rowTest.GetRecord(Record.EP_APPR_SEL_VW).GetField(Field.EP_APPRAISAL_ID).Value;
TransferPage(Page.EP_APPR_DETAIL);
Break;


End-If;
End-If;
End-For;

End-If;

In case you saw this post prior to October 12, 2007, you may have noticed that it's different (and the original posting didn't work). I apologize for that, and now that I understood the way that global variables worked in the design of the application, I was able to figure out that I needed to test by establishing completely new sessions to ensure that prior runs didn't utilize previously set global variables.

Labels: Drilling, HCM, User

Yesterday's news was very interesting. I had intended to comment on this much earlier, but ended up spending a lot of time on the phone last night talking with people who wanted my perspective on what this means.

The rumors about a big acquisition in the BI space is nothing new. In fact, a big piece of PeopleTools 8.46 and PeopleTools 8.48 was to protect Oracle from SAP acquiring Business Objects (now that this has occurred and I've been out of the company for over 2 years, I'm more or less free to talk about it).

So, Why would this be inevitable?

Good question. It's a combination of needs and market forces.

Looking at it from the BI Side

On one side, you've got BI vendors who need to get data to report and visualize. Because a good portion of this data is locked up in ERP and CRM systems, their solutions are dependent on getting data out of these big, packaged applications. Anybody who's had to built ETL maps or figure out what table to use (and what the values mean) can tell you that this is a big, hairy, painful effort.

In addition, the BI vendors, by definition, are limited in what they can provide. You see, the ERP vendors own the key business processes that people perform. Sure, you can put together an executive dashboard for management without integrating in the business process flow that occurs, but you can only sell so many dashboards. What customers really want to do is to help employees do things with the information presented in BI. This is not something that a standalone BI vendor can easily provide.

Looking at it from the ERP Perspective

On the ERP side, you've got products that are optimized for capturing data, but not getting it out. The focus on SOA as the next big thing is a perfect example of how ERP vendors look at things. SOA is primarily focused on how you can cause transactions to occur across systems (placing an order is one of the most common SOA use cases quoted). Because of this, ERP vendors have, for the most part, either outsourced any BI they provide (ala Business Objects, Cognos, or MicroStrategy), or they have defined reporting and BI in very limited terms, so that functionality gaps can be glossed over.

For those folks wondering whether SAP's acquisition of Business Objects is a good idea, they should look at the reporting functionality provided with an SAP application. Game... Set... Match!

If done properly, the things that BI firms do well can dramatically improve the core functionality of an ERP application as well as provide new ways of providing intelligence within the context of business processes. Here are some things that BI can do to improve core ERP processing if adopted properly:

1. Navigation within the ERP product can be dramatically improved. Suppose that you had a high-end query tool as the means of finding items you wish to process ("I want to manage the inventory of every product that meet some set of complex criteria"). This means that your employees can more efficiently do the most important things to your organization more productively (one might say "intelligently").
2. Conditional processing, such as approvals can leverage BI functionality. In other words, you can use common definitions for evaluating trends of key risk metrics and automatically routing the approvals to the appropriate person (or better yet, to cause the evaluation of metrics to drive business processing). A report would then be a visualization of common calculations that drive your processes (ooooh.... aaaah...)
3. Reporting can be integrated with business process, so that it's easier for users to determine what data to use, and how to get the information they need. If you can close the loop automatically, by allowing the user to navigate back into the business process, now you're talking!
4. Providing better ways of navigating and organizing things. BI firms have already had to spend a lot of time figuring out how to organize and present data, logical representations of tables, and relationships to business people (versus developers). ERP vendors could learn a lot about how to facilitate navigation, organize content, and help business people do more within their products.

Therefore, I see lots of synergies, assuming that organizational issues don't get in the way of cross-pollination of assets or ideas. In fact, I've believed for a long time that BI truly seamlessly embedded into business applications will be the next big thing for ERP (sorry guys, not SOA).

What this means to the Market

SAP acquiring Business Objects has a pretty big impact on several players in the market. Therefore, let's look at its impact to the players in both the ERP and the BI marketspace.

• Cognos - Cognos and Business Objects are the two primary competitors in the BI space. In the short-term, Cognos will benefit, because it won't be distracted from its current plan. However, it is my belief that this will play out as being very bad for Cognos. This is because Cognos's major focus in the ERP area has been going after SAP customers. With SAP owning business objects, they have a better story on integration (which is the biggest cost of doing BI). Although Cognos could move down-market to capture additional market-share, their long-term survival will be tied to their ability to integrate with their customer's data and focus on beefing up markets other than SAP (such as Siebel, Oracle or PeopleSoft).
• Oracle/PeopleSoft - I'll start by looking at just the PeopleSoft applications aspect of this. PeopleSoft has embedded Crystal since 1994, and has packaged a majority of its production reports in it (well over 1,000 of them), and every PeopleSoft customer uses Crystal in one manner or other. Back in 2004, PeopleSoft's contract with Business Objects was up for renewal, we spent a lot of time looking at what could happen, knowing that we were highly dependent on Crystal. One of the first things we recognized was that we needed to lock in a long-term contract with them. One of the second was that our integration with Crystal was originally written using windows APIs that were antiquated and needed updating. Therefore, we made the decision to embed Crystal Enterprise and utilize Crystal Enterprise APIs from the process scheduler to ensure that we would be protected in the event of a change of ownership in Business Objects. Therefore, PeopleSoft customers are relatively protected in their Crystal investment.
• Oracle Corporate - From a corporate perspective, this can't be a good thing for Oracle. One of SAP's weaknesses is the difficulty of reporting. This gives SAP the ability to address that weakness. It also puts more focus on addressing some of the limitations that exist in XML Publisher, Concurrent Manager, and Collaboration Suite that Crystal Enterprise addresses (yes, I'm sorry to report that although XML publisher has a lot of great features with respect to PDF and Excel, it has some limitations). Don't get me wrong, I still give Oracle the lead in BI integration with their applications (however, I also believe that SAP will have fewer distractions in closing the gap because it has one BI tool to integrate with one ERP suite, whereas Oracle has 4 different BI suites that can be integrated with 4 different ERP suites).
• Microsoft - This is one of the more interesting organizations affected by this acquisition. Microsoft, for a long time has embedded Crystal in its development tools. SAP has worked extremely closely with Microsoft on Microsoft Analysis Services. Now, Microsoft has built its own reporting and BI tooling and is doing a lot more development in the ERP space. I believe that Microsoft would much prefer to have a relationship with SAP that would have had the potential to make SAP more dependent on them from a BI perspective (and would much prefer to have worked with Business Objects in a way that marginalized them more).

Conclusion

In case it wasn't clear in the previous dissertation, I am in the camp with folks who believe that SAP was smart to buy Business Objects. What will be telling, however, is whether SAP will be willing to leave some tools money on the table in order to deliver the next wave of innovation in ERP. Whoever does a better job of bringing Business Intelligence into their ERP product suite will be the 800-lb gorilla (that's a prediction).

Labels: Business, Business Objects, Microsoft, Reporting