Infosys-Oracle Blog

High tech is technology that is at the cutting edge—the most advanced technology currently available. There is no specific class of technology that is high tech—the definition shifts over time. Analysts predict that this sector will always have the maximum growth but there are enough evidences where this sector has taken a beating when supply has surpassed demand.

Posted by Sandeep Chatterjee at 07:00 AM | Permalink | Comments (0) | TrackBacks (0)

As companies tread through this growth trajectory, the million dollar question here is from where the growth will come. Typically companies have followed both inorganic and organic paths to grow. While, organic growth is time consuming there are challenges in terms of integration for inorganic growth. And as consolidation happens in the market place, mergers and acquisitions are the immediate fallout.

There are various reasons why acquisitions happen, namely access to markets, better synergies, economies of scale. While in most of the cases a proper due diligence is done before a go/no-go decision, there are cases where companies are bought over a gut feeling. But one thing companies miss is the kind of ERP systems which they have.

Once the acquisition decision has been taken, every company has to go through the pangs of the integration process.  Different cultures, different policies, different systems are some of them. Leaving aside the debate about which is better, SAP or Oracle, a big challenge here is which system to follow. Company A is on Oracle and has acquired a Company B which is on SAP. The customer is confused because if it is a mixed order, he does not know whether to Order it through Company A and Company B because the two systems are not integrated. And even if we decide to have integration points between the two systems, there is the additional challenge of building interfaces to synch up the two systems.

While the logical way is to have one system, but it is not easy as it looks to be. Even if the Company B is to be brought over to Oracle, the process is time consuming and there is the additional task of educating the end users of Company B. And believe me, it is very difficult to let go of something you are so used to doing.

ERP is always a business enabler and if the acquisition has the potential to trigger growth, it makes perfect business sense to go ahead even at the cost of disparate systems. After all, this is more of a strategic move and the company is in business because of the products which it is selling and not because it has an ERP system. With SOA coming up in a big way, future integrations are going to be lot simpler. But it is always prudent to have ERP as one of the decision parameters to minimize the birth pangs.

Posted by Sandeep Chatterjee at 04:30 AM | Permalink | Comments (1) | TrackBacks (0)

Historians used two approaches to apply the past to the future: reasoning by analogy and projection of trends. The 1970’s saw the emergence of ERP systems in the form of Inventory Control Packages and Manufacturing Resources Planning (MRP II). Then came the integration of Finance, which was followed by the integration of various functional areas like Customer relationship, HR etc.

The evolution of Business Intelligence traces a trajectory similar to this. From a time of specialized tools and long multi-year customized solutions, we are seeing a convergence of enterprise applications, Data warehouse tools and analytic solutions. This is reinforced even further by the takeover and consolidation of BI vendors leaving few large players with capabilities across the value chain.

  ‘No one can whistle a symphony. It takes a whole orchestra to play it.’  ~H.E. Luccock

The age of integration in Business Intelligence, lead by Packaged BI Applications, has created a disruption in the way organizations can expect to manage their Enterprise Information initiatives.  Packaged BI Apps include pre-built extract, transform and load (ETL) adapters and business logic to tap into a multitude of common operational applications and data sources including SAP, Oracle EBS, Siebel CRM, JD Edwards, Web logs and a host of other systems. Designed for both homogeneous and heterogeneous environments, they provide a viable alternative to data residing in multiple data warehouses (and potentially multiple applications) and significantly lower the total cost of ownership.

Moreover the very foundation for this concept was an integrated cross functional view without the constraint of disconnected systems. These complete, pre built solutions provide all necessary technology and business logic to transform enterprise data into actionable insight for all users to drive better performance.

This poses a dilemma for companies which had already invested heavily in a BI infrastructure and often face the following concerns:

·         Would packaged BI work with the existing heterogeneous systems?

·         Would the BI investments till date be a sunk cost?

·         Why should packaged BI be implemented

·         When and how should packaged BI Apps be implemented?

Packaged BI Apps include pre-built extract, transform and load (ETL) adapters and business logic to tap into a multitude of common operational applications and data sources including SAP, Oracle EBS, Siebel CRM, JD Edwards, Web logs and a host of other systems. Moreover the underlying ETL tools and technologies are the same which organizations have used for existing custom Data Warehouses.

Would the BI investments till date be a sunk cost?

The existing BI investments cannot be treated as a sunk cost, because it catered to the requirements of the organization till this period and hence the worth from the investment has been leveraged already. Moreover, this data can as well be archived.

Why should packaged BI Apps be implemented?

Packaged BI Applications have the following advantages:

·         Tight integration with Oracle EBS, PeopleSoft, Siebel, SAP and others

·         Pre-defined Role-based dashboards and thousands of pre-defined metrics

·         Easy to adapt and extend to add insight to CRM and ERP applications

·         Fast time to implementation, Low TCO

·         Works with existing IT environment

·         Assured business value

·         Pre-built DW design

The next blog in this series we will talk about other key aspects of Packaged BI implementation

Posted by Siddharth Pant at 10:01 AM | Permalink | Comments (3) | TrackBacks (0)

Today, ERP is used more to drive business improvements & operational efficiencies and hence, any delays or budget over-runs could impact the business. However, most independent surveys and studies indicate that about 55 percent of ERP Implementation projects incur budget overruns. According to Standish Group, a research firm, the average IT project runs over budget by about 43 percent. Among the litany of reasons quoted (such as excessive focus on technology at the expense of business processes, communication shortfalls, project management and operational issues) estimation & bad planning rank high in the list.

While effective monitoring & control of scope, risks, communication etc., can streamline the ERP implementation, there is no alternative for a robust and accurate estimate. Given this critical need, it is surprising to note that there is no common, industry benchmark for estimating a package implementation size. Commonly used IT techniques such as Lines of Code (LOC) and Function Points (FP) do not hold good in this case since custom development is only a portion of the project. The most common technique used is experiential estimation where the practitioner derives the effort and timeline based on the ‘perceived’ size and complexity of the implementation.  Although this provides a lot of flexibility, it is inherently dependent on the ‘experience’ and ‘risk appetite’ of the practitioner and the repeatability is poor. Another shortfall of this technique is that there is no baseline size for computing productivity or comparing across projects.

To derive consistent and repeatable estimates, we have introduced a size measure called as Package Points for package implementations. The three factors that affect an implementation size are Scope, Tasks (activities & deliverables that are part of the implementation) and the project Complexity. 100 Package Points have been defined as the size to implement a “Standard Module” for a “Standard Task List” with “Simple Complexity”. The Standard Module has been defined to contain 10 business processes; each process has 4 setup activities (nodes); each node can be setup using 1 front-end interface (form); each form has 10 fields; each field has 5 possible values.

The model maintains a library of various functionalities offered by a package and functionality size in terms of the standard module. Selecting the required functionality will derive the solution size. The model also has the Standard Task Album defined, which contains the activities & deliverables of a typical implementation along with the fixed & variable impact of these Tasks to the Solution Size.  As a second step in the model, these tasks are selected to calculate the Task Impact on the solution size. Impact of the tasks on solution size varies with Complexity Factors of the project, which help in pegging the Task Impact in the range of Low (Best Case) to High (Worst Case). The third step in the model captures the impact of complexity factors on the solution size to finally derive the Package Points.

I have elaborated further details about the Package Points model in the whitepaper “Estimating the Size of Software Package Implementations using Package Points (https://pub.infosys.com/default.aspx?cid=MTI5O29yYWNsZS93aGl0ZS1wYXBlcnMvZGVmYXVsdA%3d%3d-gtOtZSHtZCo%3d) – the link will prompt you for registration on the Infosys site. Please provide your comments on what you think about this methodology and yes we have tested it in our live projects and have found that the estimate is more accurate than the traditional experiential estimates, although more involved and time consuming.

Posted by Manikandan Munikrishnan at 10:08 AM | Permalink | Comments (0) | TrackBacks (0)

Scientific American featured a thought provoking article in November 2007 titled--Trashed Tech: Where Do Old Cell Phones, TVs and PCs Go to Die? The enormity of the problem of electronic waste and the urgent need for producing toxin free electronic components could not have been discussed better. I had a serious conscience attack about replacing my old cell phone after reading the article!!

Service Oriented Architecture is a win-win solution for organizations today that have an utmost need for modernizing their legacy IT assets to sustain in a competitive world. At the same time the indispensible legacy gamut of applications needs to be retained.

Posted by Gaurav Sharma at 02:27 PM | Permalink | Comments (0) | TrackBacks (0)

Typically, the role of carton labels is to identify the packed contents for the logistic operations to ship and provide the information for the end customers to identify and receive the products.  The carton labels are generated from manufacturing packing process with the sale order line information.  These Labels are produced for every sale order lines shipped out of every the Direct Fulfillment Sites globally.  The output is the physical carton labels.

The typical system level requirements are handling a load of about 40000 labels per day, ability to produce the label within a specific timeframe, ability to produce RFID and 2-D bar codes, ability to print and reprint multiple label types, ability to support multiple printer models, ability to print labels in sequence, to name a few.

Typically, companies use middleware like ClearOrbit, Loftware, etc. since earlier versions of Oracle E-Business Suite (11.5.9 and below) did not have the capability to print bar code labels. So information from Oracle was sent to the middleware which stored the label formats and also handled the print queue. Also, the middleware had drivers for the industrial printers like Intermec, Zebra, etc.

From 11.5.10 onwards, Oracle introduced XML Publisher which has the capability to handle bar code labels within one system itself. Typically a template is designed (either .rtf or .pdf) with XML Tags at appropriate places and it is more of a skill with MS-Word. During submission of the concurrent request, the data and template are merged to produce the output. There are still some gaps like we need to procure the bar code fonts separately and install it in the server. There are still some concerns over the ability of XML to drive all kinds of industrial printers. And since the marriage of data and template occurs during submission of a concurrent request, the load on the system needs to be evaluated to arrive at a decision.

Posted by Sandeep Chatterjee at 06:32 PM | Permalink | Comments (2) | TrackBacks (0)