Infosys-Oracle Blog

Oracle Implementation projects at large organizations typically tend to span over a long period of time and quite often into years. Wide scope of requirements, complexity of design, elaborate testing efforts and smooth cutover planning, all mandate substantial investment of time. This may lead to substantial time getting elapsed between start of the project and the go-live of implementation.

During the implementation, the project teams start with a given version of oracle code and design the solution based on that version. In large implementations, substantial number customizations are built for the customer specific requirements. During project implementation duration itself, oracle may come out with new Rollup patches for the modules that are being implemented. As applying the Rollup patches may significantly impact the already built customizations and since they require significant analysis and regression testing, these new Rollup patches are not applied to Oracle instance used during the implementation, unless it is a must to resolve a project specific issue, Thus, more often than not, the oracle version that gets implemented at go live is the same that was started with at the time of design.

Further, after the go live, the projects teams and client business teams are focused on making the production environment stable. The thrust is on making sure that all the built components and solution work as has been expected as per the designed solution. So it takes some more time to make sure the production environment is stable and running smoothly and during this time the new Rollup patches are not taken up for application. Further, successful implementations are very close in being able to provide to the customers almost all the functionalities that they sought from the implementation. With requirements being met, the client organization’s IT and support team’s next goal is to ensure continuity of systems to the business and operations. Due to this, the latest Rollup patches do not get applied to the production environments even further down the line.

Also, since the oracle implementation are large initiatives for the client organizations, they tend to be sticky in the sense that customers tend to harness the implemented oracle system for a good number of years before planning for any major change unless it is required by a new initiative.  And, in some situations, the cost of large implementations leads to client management ramping down teams and focus on maintaining the system rather than bring any further changes that may impact the existing system. This tendency further causes delays in taking up the Rollup patches for application.

Thus multiple years would have passed on since the start of the Oracle implementation without the newer Rollup patches being applied to the system. As a result of all this, the oracle version in production would have become woefully out of sync with the latest versions from Oracle. In case of some rapidly evolving oracle modules (e.g. WMS), this gap becomes even more pronounced.

This can be a very drastic situation for production environments that are at the core of running large scale business operations. What further increases the gravity of the situation is the fact that this criticality may not be borne out to system managers until the production system runs into a major issue with Oracle standard code. When a major production issue occurs and it needs to be resolved in the oracle code, then to be able to fix the issue Oracle support expects the client systems to be close to the latest system versions vis-à-vis the program files pertaining to the issue. Often times the issue may not be replicable within oracle support instances due to version differences. Then oracle development and support further necessitate that the production system version be the latest. Moreover, it may not be possible for oracle to fix the issue in isolation as changing just few of the files may have impacts that are widespread in the system.

So, it might lead to a situation that there is not an existing oracle patch to resolve the issue and Oracle is not able to provide a one off customer specific patch. Even if it is possible, Oracle may take some time in building a one off patch and testing it. If the issue is so critical that it is stopping the operations, this time lag may lead to huge losses to business. This can cause a scenario wherein the latest rollup patch needs to be applied urgently. As this would require significant regression testing, it will significantly delay the resolution time of the issue. Also, applying the rollups within a short timeframe may not leave enough time for proper planning and rigorous testing of the patch.

Therefore, it is highly imperative for system managers to ensure that the Oracle versions in production are timely updated with latest rollup patches. The application of rollup patches should be taken up in earnest and due importance should be paid to this activity. This will help in planning properly for the application of these patches and performing rigorous end to end testing of the same. Further, this will ensure that the system is capable of handling any eventuality if it arises. The resolution turn around time for any critical issue will be short and business and operations will be affected to a lesser extent in case of issues.

Also, with the system being on the latest versions, any new initiatives and new solution that need to be brought in to the oracle system can be taken up quickly as and when they come up and implementing these solutions will not require an extra effort of bringing the systems in sync with the latest version. Overall, it makes a lot of business sense to continually asses and evaluate the new Rollup patches provided by oracle for application in the production systems and ensure the sustainability of the system.

Posted by Pragyesh Dwivedi at 02:08 AM | Permalink | Comments (0) | TrackBacks (0)

Taiichi Ohno, the father of Toyota Production System says, “Transportation is a waste and has to be reduced”. Transportation within the organization is considered a waste which does not add any value. What many overlook is the fact that transportation does not only imply inside the manufacturing facility but also outside it. The outside transportation can, not only help add value but also act as a differentiator. With many companies implementing Lean Manufacturing concepts, it is of paramount importance that the Logistic strategies are also aligned to it. Let us analyze the different wastes in transportation and how they can be reduced using Oracle Transportation Management (OTM), a Transportation Management System (TMS) by Oracle.

With Lean Manufacturing implementation the supplier and the manufacturer collaborate to tune themselves to listen to the customer demand and produce only what is required. They continuously aim to reduce inventory and create a pull system. This requires the transportation to have frequent truck runs with lesser quantity. Most organizations prefer going for Milk Runs with the right size equipments.

Customers also prefer smaller and frequent orders and this reduces the opportunity for full truckloads and direct shipments. In this case organizations have to look at other modes to transfer the goods. Mostly LTL transport is looked at. In many cases the orders are such that they are not fit for LTLs (more weight or volume) but do not fully utilize the full truckload capacity either. In such cases the planners forget the fact that multi-stop shipments can fully utilize the trucks.

One of the key factors for instantaneous response is proper communication between the carrier and the manufacturer. Visibility of the shipments for various reasons like warehouse planning, customer queries etc. is essential. The delivery times for all the carriers needs monitoring so that the efficient carriers can be identified.

To implement lean transportation, organizations are looking at their transport network very closely. Every route is being rationalized so that better vehicle utilization can be achieved. This exercise needs to be done continuously for reduction in the waste.

For some of the above OTM can be very useful, become partners for waste reduction and make the system lean.

Ø  The schedule for the Milk Run is entered in OTM and the shipments are formed accordingly, helping the manufacturer have several runs for a pre-defined route.

Ø  The planning engine of OTM takes care of the customer order planning. It helps in giving you the right mode with the right equipment to deliver the shipment to the customers at the right time.

Ø  Planning engine takes care whether to build a Multi-Stop, LTL, Direct or a Multi-Leg based on all the constraints on the order.

Ø  OTMs powerful Supply Chain Event Management tracks the shipment which helps in planning at the warehouse and answering customer queries quickly. It gives immediate information about the current status of the shipment. The shipments are routed to the correct Dock so that the time wastage on unloading is reduced.

Ø  Cooperative Routing feature of OTM identifies repetitive routes and helps in determining the right number of vehicles required for a particular route. This supplements the Transport Network rationalization.

Ø  Fusion Transportation Intelligence module provides a means to monitor Key Performance Indexes like number of on-time deliveries, number of late deliveries, total load pre lane etc. These help in making strategic decisions and revise the carrier collaboration programs to make the supply chain more effective and leaner.

Reducing wastes in transportation is one of the key factors for making the supply chain lean and OTM can act as a strategic partner to achieve it.

Acknowledgement: Anirban Roy

Posted by Nilabja Dey at 04:30 AM | Permalink | Comments (0) | TrackBacks (0)

From my past experiences, I have observed that we often build a data warehouse as a way of integrating multiple sources of data to gain effective business intelligence. This is both time and resource consuming and also can potentially disrupt the IT roadmap of an organization if not handled with utmost maturity.

In this rapidly changing world of technology, new paradigms have evolved which have the possibility of simplifying the process of aggregation of multiple sources. One such technology which I found very exciting is Data Federation technology which is also known as Information-as-a-service, Data Virtualization or EII(Enterprise Information Integration).

Heart of this technology is a “virtual database” or a Federated Database as was defined by McLeod and Heimbigner long back in 1985. Simply speaking, a virtual database is storage of data definitions and not the data itself. The virtual database will have information about the location of the data.When a single call is made to a virtual database, the technology ensures multiple calls to underlying databases and is also responsible for meaningfully aggregating the returned result sets.

Primary benefit of the above approach is that data need not be moved from the source systems for analysis.It also saves the cost of building and maintaining a permanent warehouse.  Since data is not being moved, this enables quick and real time data delivery. 

The biggest challenge that needs to be handled for such a system to deliver what it promises is the heterogeneity of the DBMS giving rise to naming, schema, domain, model conflicts. These can be  typically handled by designing multiple stacked-up schemas which accurately translates
the data model,as visible to the user, to actual data models of the component DBMS.  

Areas where this technology will have ready acceptance are the organization’s divisions (like fraud detection units) which heavily rely on real time intelligence from disparate systems to drive business. Data Architects may also find this approach very efficient for maintaining master dimensions which are typically time consuming at an enterprise level.

Vendors like Oracle, SAS, Informatica etc have already lined up extremely comprehensive solutions in the market. Now it’s on the Consultant and Architect community to go out there and propose solutions which are truly ‘out of the box’!  

Last but not the least, what is the experts’ take on this?
Talking to some of the data warehousing connoisseurs, I felt people are divided on the appropriateness of this approach of replacing a data warehouse with federated architecture. Weighing in the pros and cons, I can safely conclude that at this point of industry maturity, this approach definitely merits an augmentation to a traditional data warehouse but we need to wait and watch how best it evolves to become the mainstream.

Posted by Dwaipayan Das at 11:20 AM | Permalink | Comments (2) | TrackBacks (0)

The recently released movie 3 Idiots, based on 3 college graduates experimenting and challenging a deeply rooted, established education system, has turned out to be quite a huge hit in India. Taking a cue from the 3 Idiots, I cannot help but ruminate on the impact that the 3 Critical Changes will have on how the India Inc does its business? Will India Inc emerge a winner or a loser? There is no doubt that all three financial changes i.e. IFRS, GST, Direct Tax Code, which are supposed to be effective from 2011, will have some effects. Even if implemented in silos, they’ll change the way business is done and the financial statements are prepared. As an example, IFRS is not just an accounting change but it will also have an impact on overall policy changes that effect each and every stakeholder of the organization, be it an employee or a shareholder

 

The 3 changes still have a lot of loose ends. They still need a lot of discussions amongst different stakeholders in order to be finalized. Though some work is happening in some fields but the pace of progress may not be good enough to leave sufficient time for them to adopt these changes.

 

So, will India Inc be ready to implement all or some of it will get pushed?  May be IFRS would have to be given a back seat because it involves changes in various acts and laws or GST where paper is still not released for public debate or Direct tax code with a lot of ambiguity still to be looked into..

 

As the year 2011 unfurls, so may the answers to these questions. Lets wait and watch for more…

 

 

Posted by Giriraj Somani at 01:53 PM | Permalink | Comments (0) | TrackBacks (0)

Russia, post USSR days, though small has its own share of uniqueness. It has 83 states/provinces and 11 Time Zones. Given the fact that there are unique legal requirements, any ERP implementation becomes a challenge.

Some of the Statutory requirements are to have a Parallel Accounting System, one account system is to be built in accordance with the bookkeeping rules and another one in accordance with the tax accounting rules. All Customer documents and all backup and sub-ledgers for tax audit need to be in Russian. Shipping documents like Invoice-Factura (VAT invoice) and Consignment Note need to be in specific layout and content in Russian language and should accompany any shipment.

Though Oracle has a localization solution for Russia (in terms of localization patches), 1C is the most prevalent software and has close to 1 million customers in CIS. There are multiple versions of 1C in the sense that the base code remains the same while various companies have developed their own code over the 1C Framework. 1C Bits is the most prevalent one.

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