eBusiness suite implementation projects are complex, time consuming and require extreme planning. These projects vary in nature. Fresh implementations, rollout to new divisions, adding new products to the exiting portofolio, projects that are direct result of mergers and acquisitions or simply just enhancements to process and so on. Each project is unique from solution and industry perspective and has different needs of its own.
But whatever is the nature of the project we have different teams working towards a same goal (question of who is doing what). Each project goes through several stages: from gathering business requirements to production go live (question of when). In this process we go through a number of testing cycles to keep the progress in check.
These questions of who, what and when drives the demand for number instances of eBusiness suite and when they are needed. Typically we go through the following process (simplified) before we go live.
Typically we prepare the base instance at a desired application release level. We setup application parameters in this instance for basic out-of-the-box functionality testing.More the number of applications more the setups and complex are the dependendencies. In stage two we copy this instance for testing. This might lead to some patches identification. Usually we apply these patches to patch instance first then to functional instance. If the patch pass the test then it will be applied to the base instance so that the same issue will not recur again in the future cycles of testing.
All these setups have to performed manually. These setups are interdependent and need to be setup carefully as some of them are irreversible. Business Accelerators help in these setups to a great extent.
During testing if we make any changes to the setups, we make sure all the changes that we have made in the testing instance are applied back to the gold (base) instance. Without iSetup we have to make sure to document these and apply them back to the gold (base instance). Mistakes can happen here too!
From here the project takes off. We copy this base instance for all different teams in the project for their needs. Development gets a copy to develop code for the conversions and extensions, DBA team gets one for patch testing, change management or system admin team for migration of code or security testing so on. Here is the issue. If the functional team decides to change any of the setups in their instance, they have to be made available for all the teams. Again without iSetup we have to make sure to go and apply the change to base instance and copy that instance all the instances again, or make change in all the instances. Both these options involve considerable amount of resource idling.
iSetup is set to change all that. Uma Prabhala has documented 10 good reasons as to why you should use iSetup. Striking among those are :
- Setup dependencies.Once setup manually, for the rest of the instances you do not have to remember the setup sequence again. The dependencies are taken care of in selection sets.
- Reporting the difference between setups among instances. Great feature to use when we want to check the changes made and migrate only what we need.
- Migrating incremental setups from one instance to another.
- Custom code migration by using custom selection sets
- Download the setups and tranform the data and upload the transformed data. Which means, if you have to change the name, you can download the data from source setups and change names and upload.
- And the FAQ document that you can find in this link tells you that it is absolutely free!
You can clearly see how isetup streamlines the process by comparing the figures with and without isetup.
Just go give an example, in a recent project, we had to collapse three operating units into one as the three different companies in the same line of business got merged.
There were three options :
- Leave the systems as they are and assign three responsibilities of three operating units to the users who are suppose to access information
- Create one more operating unit in the same production instance and convert all the existing three OUs data into newly created one.
- Create totally new instance,setup from scratch and convert what need from old instance.
We chose the third one for many reasons.
Hence we had to copy the setups one by one.If we had iSetup, this could have been painless as far as the setups are concerned (both instances were on same release, which is mandatory for iSetup to be used. It does not support upgrade, only moving the setups between instances at same patch level).
One more thought. Some more creative uses of this product include :
Conversions.The hardest part in conversions is to transfer the files from desktop to servers so that the loader programs can them up. By creating a custom selection set, you can upload the file from your desktop (say your open sales orders). The contents of this file will be loaded into a staging table using the interface method that is registered earlier (this uses the control file is called from the FNDLOAD to load the data from your data file). After it is loaded you can call custom program that either loads into interface tables or calls the Sales Order API to create orders.
From to day to day operations perspective,you can even use this product to load say, AP invoices, from a spreadsheet to interface tables to create invoices. This is an alternative to the Web ADI.
From change management perspective, you can also migrate code from instance to another with some careful planning.
But I am sure this product has a lot of potential and is well on its way to revolutionize the way we are implementing eBusiness suite.