My follow up posts will probably center on new features in R12x. This however, is a special edition/1st post special! 

In my spare time I took on the pet project of installing EBS on a junked desktop my folks had gathering dust in the basement. I had heard of doing this off and on in the past but never had the gumption (or linux skills) to attempt it. This is a great learning experience for the functional consultant who hears phrases like “APPL_TOP” and “database listener” thrown around casually without actually knowing what they mean. If you have spare time and want to wow your friends take up ORACLENERD’s EBS Challenge located here.

The guide is the best most direct method to getting EBS up on a dedicated “server”. If you want to do this on a utilized PC then a VM is the way to go. Use VW Ware or Virtualbox. Oracle VM is a whole different animal as it sits directly on the system (no OS) and requires more skill to setup. Other points to mention for noobs:

- Do go with Oracle Enterprise Linux as the OS. It’ free from eDelivery and setup is a snap. If you’ve played around with any Oracle installation guides you know that Windows installation is much more of a pain in the arse and requires additional configuration specifically for the database tier. Of course this means using the dreaded command prompt (every non-geeks worst nightmare) but a little study-up on Linux.org -perhaps a day or so- and you’ll know all you need to get setup. I went into this with 0 linux experience, Im about as green as they come.

- If you’re like me and scrapped together the minimum hardware requirements (320 GB disk, 2 GB RAM, single core etc.) then be prepared for excruciating lead times for getting this thing off the ground. The staging files take up 50 GB alone! Also, do a memtest on your RAM. I kept having the rapidwiz installer tell me that my 2.5 Gigs of RAM were cool. I would procedd with the installer and the system would blank out and reboot. the reason? Bad RAM. Memtest to be sure that your rig is fully functioning and don’t trust the installer on its RAM readings.

- Please, I cannot stress this enough, use a Download Manager, I had several files get corrupted that blew my install b/c i was too lazy to get one..I use DownLoadThemAll. its really just preference though. In a related note, download and install Oracle unzip utilities. this is the program that (using the command prompt) you should use to extract the zipped files.

-Most issues I came across were with regards to missing packages. If you are missing any, go the oracle public yum and follow the directions. This is a free repository of sorts and once installed can list all the packages available in the RPM manager located in the OS gui. (RPM= package), simply reference the install requirements on My Oracle Support with what’s been installed on your OS. If one of them is unchecked, simply check it off of and install it. Sometimes this stuff is that simple.

-Rapidwiz wil do pre and post install checks. Any error must be resolved. 90% of my errors on these were related to permission grants on the OS. You’ll be creating users/groups and assigning them permissions. Do yourself a favor and let the Linux admin on your next assignment worry about security. By nature its a locked down OS and it should be, but we’re not hosting a Prod environment. In other words, open up everything and let the installer do its thing, unless you’re into sysadmin type stuff, in that case, carry on!

ok whew. All set? Again the EBS challenge series and the rapidwiz install guide (located at OTN) will be your guiding lights in this quest. I was simply pointing out a few details that technical white belts like myself had to figure out the hard way.

“Give a man a fish; you have fed him for today.  Teach a man to fish; and you have fed him for a lifetime”

As a consultant/contractor, it can be tempting to do as much as you can for the client on your own, making yourself appear indispensable.

However, this may not be in the long term interests of the client or yourself, especially when involved in first time Oracle e-Business implementations.

An alternative view is that you should be able to make yourself dispensable by ensuring that the client is able to be self-supporting once the project is over, the money has run out and/or you decide to move on to your next consulting challenge.

For this to work, you need to build this into your consulting approach at the outset of the project.

A feature of projects with the best outcomes is that the client assigns their best people, rather than those who they can afford to move sideways into “Special Projects”.

Typically, the client people will “buddy up” with an external consultant, perhaps on a module by module basis, resulting in a combination of business specific and Oracle product specific knowledge.

It is crucial that once the project is over, the client people are left with an enduring understanding of the workings of Oracle, instead of viewing it as a “black box”. Yes, the consultant may also leave with a better knowledge of the client’s (and their related industry) practices, but this isn’t why the client engaged you in the first place.

So how can this be done, especially given tight timeframes?

The key is to immerse the client expert in both the analysis and resultant configuration processes, even going as far as making them responsible for completing the relevant documentation (eg MD050, BR100 etc if using AIM). More importantly, for key functional configuration decisions, allow the client expert to experiment with the various options available by themselves.

A real-life example occurred for me when I was leading both the Receivables and Assets streams of a large implementation project. Fortunately the client had appointed the AR manager to the project. When we pondered how best to set up AutoAccounting (it was Release 11.0.3) to meet the complex government fund accounting requirements and the introduction of GST, we decided that it he should take full ownership for the design of this aspect.

After a session or two on the basics of AutoAccounting, he spent the necessary time experimenting with the various permutations available until the required outcomes were achieved. This exercise resulted in both a deeper and broader understanding of the end-to-end flows within AR. Once the client was live, they were totally self-supporting, because they took the time to understand the critical components of Oracle AR. They not only knew what worked and didn’t work, they knew the “hows and whys”.

Of course, as the consultant, you should always be there to provide support, guidance and review. It doesn’t matter who compiles the Configuration documents, what matters is that the client has the skills to continue, well after the project team has packed up and gone.

You’ve decided on the software you need, the business side has bought into it, and you’ve even picked your integrator. Now the hard work begins: Making sure that your software deployment strategy sets your company up for success, and that means making sure business, IT and implementation partners are all speaking the same language when needed.

First, we need to understand that Business, IT, and the Implementation Partner are coming from different perspectives.   Every party has a knowledge gap to address.  Business best understands their existing business model and the underlying success drivers.  The Implementation Partner understands the packaged software and has multiple years of implementation experience.  IT best understands how technology supports the existing business model as well as how best to utilize existing corporate IT technologies.  Alignment is generated only when a common understand of the business model, packaged software, and technology capabilities are shared by all three parties.  When this alignment occurs there is effective communications and faster decision-making.  Decisions move implementations forward. 
Following is a recommended set of steps to develop a common understanding for effective collaboration:

Step #1: Document existing business processes

It is an area that I see many packaged software implementations lack.  The typical challenge I hear is “Why document my existing business processes if I know they are changing?”  Here are my reasons:

1. Business users usually do not have a consistent understanding of their business model.   Going through the exercise of documenting business process will highlight these differences and drive deeper understanding.
2. Documenting the existing business model will enable you to highlight the EXACT organizational changes that will occur.  How can you manage organizational change when you do not have a clear understanding of what’s changing.
3. Business process maps can be a key source of information to quickly educate IT and the Implementation Partner on the existing business process model.

Step #2: Educate IT and the Implementation Partner on the existing business model

Business should take a formal, iterative process to educate IT and the Implementation Partner on the existing business model.  The entire project team should be involved in this training and should progress from a solution-level overview to a detailed business-role level.   Following is a suggested approach for conducting this training:

Step #3: Complete packaged software training BEFORE the Implementation Partner arrives

Just as it is important for your Implementation Partner to understand your business model and your language it is important that Business and IT have an understanding of the packaged software and its language.  Effective communication is a two party effort.  Taking the required packaged software training before the arrival of your Implementation Partner will enable you to more effectively work together.

Step #4: Have the Implementation Partner conduct supplemental packaged software training

Education is an iterative process – you will never learn everything you need to know for support packaged software in one class.  Packaged software provides provide foundation training.  I always say that the Implementation Partner completes your packaged software training.  Implementation Partners have hands-on experience with configuration and maintenance of packaged software solutions. 

Step #5: Implementation documentation should be more business-oriented

Nothing encourages alignment more than being able to think like your end customer.  Too often we create project documentation that focuses more on technology than business reasoning and justification.  There are times were I am guilty of moving too quickly from what needs to be done to how will it be done without understanding why does it need to be done.  At the end of the day we build software to drive business results.
 

Business to IT alignment is a strategic goal that can only be reached by taking tactical steps to bring Business and IT closer together to generate mutual understanding and trust.  Implementing packaged software is an opportunity to generate greater alignment by developing a common language for effective collaboration.  When alignment is achieved then decision-making is effective resulting in a greater opportunity for success.
 

Adapted from the book “Maximize Your Investment: 10 Key Strategies for Effective Packaged Software Implementations” by Brett Beaubouef. Brett provided Oracle Contractors members interested in his book with an extra discount code: Just use “maxurinv” when checking out.

This is my first blog post and I decided to start with one of the most asked features of Oracle Retail’s Demand Forecasting (RDF) package: Product introductions. It’s going to be covered in three posts and this is the first one.

Product introductions is a very common and frequent process for retailers. There are many variations of it, e.g. there are seasonal products which could be introduced every year (Santa Claus dolls for Christmas), variations of existing products (new taste coke) or completely new products (new mp3 player). How do big retailers manage the amount of work that needs to be done for new product introductions? How do they know how many new products to order in advance if they have no or limited historical data?

RDF is used to support this process. Before I start explaining how one can use RDF to automate some aspects of the process, let’s look closely at what parameters are usually considered by the retailer when introducing new products:-

• sales and gross margin on sales;
• store penetration, i.e. how many stores are going to be selling this new product;
• shopper penetration, that is market share in the target group;
• cannibalization and impact on the sales of the whole category, e.g. are the sales of classic Coke going to be affected by this ‘new taste’ Coke? If yes, how much?
• repeat purchases

RDF allows retailers to generate sales volume forecasts for new products by using a process called Cloning. Cloning allows users to generate forecasts for products by copying or cloning history from other products. Users can map items that have similar business cases, clone their historical data and begin generating forecasts. The products that have been cloned are called Parent Items. Usually, users can pick up to three Parent Items and select for each one of them a scaling factor. This factor will adjust the volume of the historical demand of the Parent Items according to the newly introduced item.

Cloning provides the ability to generate forecasts based on not only the historical data but also the promotional calendar, too. I.e. Sometimes the product that is introduced is set also on promotion and thus making the forecast process more difficult. In this case RDF is designed to look in the historical and promotional data that already exist and figure out the increase of the normal sales that the same promotion has on the Item. Then it will apply this increase proportionally to the upcoming promotion.

Vanilla cloning as it is described in this post applies to most product introductions. However, more complicated business requirements can be raised when discussing new product introductions. RDF can handle more complex functionality, too. Such topics will be discussed in the next blog post.

I began this year with a 3 week vacation– the longest I’ve had since I started contracting 5 years ago  - and decided that it would be a complete break from emails. I’ve met many contractors who never take more than a few days break in case they can’t get back on the job market again and it is an aspect of contracting that much of the time one is probably not more than a few weeks away from potential unemployment.

I returned home to find several hundred emails of which 90% were either work-related or bulletins from computer societies, SIGs, and user groups, plus e-magazines and invitations to seminars, exhibitions and suchlike. This didn’t include junk mail which is automatically filtered off but did include innumerable letters from job agencies informing me about jobs which they thought I should apply for. I sometimes ponder over the need to constantly keep my CV profile up to date as I am only ever able to undertake one contract at a time and therefore by definition will not need to worry about any job offers until I’m available for work. 
Having spent 2 days sifting through them all it seems that very little required my attention during my absence and I’m still in the same contract as when I left. I wonder about all those people I saw visiting the internet shops each evening, browsing through their emails, keeping track of day-to-day goings on back home and sending off daily bulletins about their holiday and am now pleased I resisted the temptation to join them, opting instead for the sunshine and cocktails.

On reflection though, my contract expires in 2 months time so I should probably be spending time updating my CV instead of sitting here writing blogs. And maybe I shouldn’t have deleted all those job emails.