Infosys-Oracle Blog

Guest post by
Navpreet Singh, Lead Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Late 2009 and 2010 witnessed quite a few mergers as economies took a U-turn from the trough of sluggishness.  Now, with gloominess having ostensibly bottomed out, corporate restructuring is likely to regain momentum.  Amidst M&A, the "soft" element of integrating human culture remains paramount during any change management process. These challenges get magnified by the existence of non-uniform standards and discrete IT support systems amongst merging entities.

Many a times, software applications initially used by the bigger partners are invariably rechristened in merged entity. Decision criteria that help evolve the basket of IT systems are indeed complex. Apart from technical challenges the single biggest challenge is presented by the human element. Organization structure is still shaping up in parallel while decision for some of these systems is being firmed up.

Mergers and acquisitions always kick-start on a high note but in one way or the other they fall short of initial euphoria. Information delivery systems across value chain are impacted during the integration process. With increasing advancements in technology imperatives it is imminent that a multi-prong strategy is deployed to make the entire process a success. A smooth transition would involve overcoming the technology, human, and financial barriers to draw an all-round synergy.

Top five ingredients that IT teams need to be top in their journey are outlined below:

Engage with the right people - Amidst realignment of authority at times it may become a challenge to identify the true stakeholders. This is all the more true when critical staff is diverted into organizational decision making, or if key people leave the organization during the integration.

Master data harmonization - Metadata holds the key in definition for any EPM application. Gaining a good hold on this element sets the path for a smooth migration to integrated information delivery.  Some of the other things to be considered include fulfillment of multi-jurisdiction requirements.

Data integration strategy - Quite often the transaction systems are on different platforms. This makes the pursuit of EPM integration a moving target. The data source definitions and integration carry the biggest weight.

Standardize - It is imperative that decisions on the key financial process arrive early on in the walk across the integration path.

Process re-engineering - M&A invariably bring a change in the manner things are dealt.  Quite often there is an urge to intertwine process improvements to M&A initiatives.  More often than not this ambitious desire turns counter-productive.  The mantra of success is to keep it short and simple.

There is no single answer, no single pattern for integration, no golden rule for success. If it works - it works !

Posted by Guest Blogger at 10:37 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Rinku Das, Project Manager, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

What is the future of Oracle Forms applications? Is Oracle going to support Oracle Forms in near future? There are many such questions worrying the developers working on forms and the customers using forms in their applications. All these are scary questions for application developers who are working on Oracle Forms for a long time and are not familiar with Java. These developers may not be in a position to immediately migrate/move to new technologies/tools like ADF, Fusion Middleware and SOA. These are the common debates now-a-days amongst Oracle developers.

Oracle has released Forms 11g to support integration with Oracle Fusion Middleware and is an important component of Oracle Fusion Middleware 11g. Oracle Forms Applications are deployed on Oracle Fusion Middleware which can be accessed on the Internet. Before deployment, we need to upgrade earlier versions of Forms to 11g. For Forms version 6i and above, Oracle supports direct upgrade to 11g. For versions earlier to 6i, first they need to upgrade to 10g and then to 11g.

Oracle Forms 11g will still follow the 3-tier architecture - Client Tier, Application (Middle) Tier and Database Tier. In Forms 11g architecture, Fusion Middleware and Weblogic Server are included to make Oracle Forms Applications accessible on the internet. This architecture can also be named as Oracle Fusion Middleware Forms Services which contains components like Forms Client, Forms Listener Servlet and Forms Runtime Process.

How these components in the architecture are connected to each other?

• Client Tier: Forms Client component is a part of client tier. When user starts a Forms session or opens an Oracle Forms Application in the browser, a Java Applet is first downloaded from Oracle Fusion Middleware Application Server. This is a onetime activity and is cached on the client system. Once downloaded, the applet sends a request to start a session to the Forms Listener Servlet which resides in the middle tier. To run this Java Applet, JVM is required and Oracle has recommended using Sun JDK 1.6.
• Middle Tier: The Forms Listener Servlet uses Weblogic Java Runtime in 11g to create a communication between Client and Forms Runtime Process. For each client, a Forms Runtime Process is created to establish an Oracle database connection (Database Tier) for the Forms Client. The Forms Runtime Process is also responsible for loading all the forms related objects to be rendered in the page.

For large/complex Oracle Forms Application, which is using Oracle Forms version 10g or less, manually upgrading to Oracle Forms 11g will not be an easy job. It requires additional budget, more resources, can't guarantee about the quality of work & the quality of testing, and finally all these will end up increasing the project duration.

Recently, I have attended a session on "Upgrade and Modernize Your Application to Forms 11g" organized by PITSS.CON. PITSS has demonstrated an automation tool using which we can upgrade Oracle Forms Applications to 11g. By looking at the demo, it looks like a very reliable and strong tool. Few points which PITSS.CON has highlighted are - it can do impact analysis faster, can identify obsolete functions/objects from the existing Forms versions, maintains the coding standard for consistency, reduce testing time, reduce project duration & budget, and finally will convert to an Oracle Forms Application 11g which can integrate with Oracle Fusion Middleware.

Posted by Guest Blogger at 1:47 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

The Oracle Utilities roadmap for Business Intelligence (BI) has become clearer and headed in a direction of strength.  Going forward Oracle Business Intelligence for Utilities (OBIU) replaces the unpopular Oracle Utilities Business Intelligence (OUBI).   Don't let the similar names confuse you.  They are two separate products.  Unlike its predecessor, the OBIU is built on OBIEE framework (Oracle Business Intelligence Enterprise Edition).  With OBIU, Utilities will have fewer challenges with the installation and implementation of the Business Intelligence Framework, Portals, and Dashboards. With the ongoing implementation of smart meters and smart grid projects, more and more data will become available to a utility.  Smart Grid data stored in the BI can be used to plan power distribution and influence consumption and decrease having to purchase power from other utilities at more expensive rates.  An effective Business Intelligence solution is needed to mine the data and display it in useful reports and dashboards, which enable Utility executives to improve their decision making abilities by having near real time and historical information related to demand, usage, trends, and outage risks, and asset usage. 

Using Near Real Time (NRT) data and dashboards (instead of directly querying the OMS database) keeps the Outage Management System operating at high performance levels and enables key stakeholders (like the media and executives)to have access to critical and current information.   While is not at real time, it is extracted at regular frequencies measured in minutes.  Executives and supervisory personnel are able to see and make use of system wide summaries of outage statuses and detailed customer information.  With near real time monitoring, an eye can be kept on critical distribution operation processes, restoration progress and projected restorations to come throughout major events, like restoring after a hurricane. It will help Utilities to make support decisions like whether to request support in the form of mutual aid crews from a nearby utility so that large outage events can be restored as quickly as possible.  Reports during storms are possible that use near real time and historical data combined to calculate estimations for restoration times of major events like blizzards or earthquakes.  

Every utility keeps its eye on certain restoration metrics, like Customer Average Interruption Duration Index (CAIDI) or Service Average Interruption Duration Index (SAIDI), Customer Average Interruption Frequency Index (CAIFI).  Data kept in the BI database is capable of reporting this and much more.  Reports are possible to keep awareness of the most troubled spots in the network, and enable proactive action to prevent many outages from ever occurring.  By identifying the problem spots, investigation of root causes is easier, which results in fixing not only the symptom (the outage) but also the problem (root cause).   For example, if the utility knows that certain areas are more prone to squirrels or certain birds causing high numbers of outages, the appropriate preventative action can be made.  Another question the utility's engineers can see from the data is if and when certain circuits tend to get overloaded. Planned switching can be performed to avoid future overloads.  These are only a few examples of the benefits which Business Intelligence can provide to Utilities.

Have you begun working with the Oracle Business Intelligence for Utilities?  What reports and dashboards bring the greatest value to your region of the country?  I'd love to hear the comments on this post and the BI success stories.

Posted by Ross Shaich at 4:19 PM | Permalink | Comments ( 1 ) | TrackBacks ( 0 )

Oracle Product Item Master (PIM) was released in Jan 2008. PIM was touted as an innovative master data management application that allows global retailers to create a single, enterprise view of all product information to help unlock value from within the business.

With much water having passed under the bridge, where does it stand and what is the Product Master 2.0 for Retail, read on for my perspective on it!

 

Retailers are increasingly moving towards a healthy mix of online sales to go with their store based retailing concept. Product Master implementations so far have focused on creating a single system of truth across various divisions, departments and/or stores of a retailer. While this had its own challenges in terms of retiring the multiple item masters that are prevalent in the Retail industry, it often fell short of the core aspects of merchandising, price optimization and supply chain relied item data requirements. 

Most Retailers have realized the benefit of having a clear MDM strategy for managing product across channels and divisions that is specific to the retail needs . While majority view the item master in Oracle Retail as the Master, they are quickly seeing the benefits of maintaining a separate Master Data approach that not only integrates with but leverages the core merchandising aspects of Retailers.

Another challenge for the 2.0 version of implementations is going to be to create a seamless integration between the online world and the brick and mortar world. Shopping experience online is vastly different from a store based one in terms of the product information. Apart from the online vs Store based Retail difference, here are few important aspects that have a direct impact on any Retailers MDM 2.0 approach

1. Items are classified differently online vs real world stores. Any product master should be able to cater to this basic need.
2. Retailers get a lot of item information through their supply chain, this needs to be integrated and enhanced before it can be published out to the stores or the web. PIM for Retail is certified out of the box for GSDN and 1sync data pool.
3. Retailers often engage in substitute/complement logic in merchandizing
4. This substitution is also applicable in pricing and price optimization. Any MDM tool has to be able to provide this core functionality for retailers.

These are some of the concepts that have to be part of any Retailers MDM approach, with PIM for Retail Oracle has identified the need to create a Retail specific product offering, this will become the growth engine for Product master 2.0. As the economic recovery takes hold, MDM and Product master is one area that will increasingly get IT funding as Retailers catch up with the new trends of retailing.

Posted by Venu Kotamraju at 7:36 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Kartik Kamalakar Deshmukh, Senior Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Having been part of the 'brick and mortar' industry in the initial years of my career, I have always appreciated the pace of innovations and customer centric solutions that the Information technology sector has been offering its customers. Equally importantly, the customers too have been extremely receptive to these innovations and ready to experiment with newer technologies and solutions.

With companies investing heavily on the technology side to become more agile, flexible and efficient, new set of opportunities and challenges have opened up for the IT Industry. Recessionary economy, competitive pressures, are forcing organizations to closely look at their IT landscape, to make it lighter, faster and cost efficient. They are looking for technology solutions that are faster to implement, easy to maintain and have a low TOC.

'On Demand' solutions promise to offer these capabilities. But is an 'On Demand' solution panacea for all the IT needs? This is where a CIO needs to be more discerning in making his decision and consider his organization needs and constraints before committing to an On Demand solution for a business area. He needs to ask himself few questions before he decides to go for an on Demand solution:

1. Am I looking at implementing standard business processes?
   If your business area has a pretty straight forward, standard business process that needs to be automated, you may want to consider an On Demand solution. These can be implemented pretty quickly as a hosted solution, without too many customizations. With short 'Time to delivery', business can be brought on to the new solution fairly quickly.
   However, if the business processes are complex, with branching and complex business scenarios, customizing an On Demand solution, may not be the right approach.  It threatens to take away the basic advantages of having an On Demand solution - Faster deployment at a cheaper cost.
2. Am I comfortable putting my data in a shared environment, with little control over it?
   If you answer 'Yes' to this question, On Demand solution can be an option. In an 'On Demand' solution, the data does not reside within an Organization's boundaries (physical or network). Also, chances are that the place where your data is stored is shared by other Organizations too. If there are no concerns around data privacy or Federal Compliance requirements around data maintenance and organization's strict control over it, an On Demand Solution can be considered.
   For Organizations from Pharma and Banking/Finance sector that have Customer PII (Personal Identifiable Information), Company confidential data, New Product R&D data that is very sensitive from compliance and confidentiality point of view, the standard multi-tenant, single version, solution may not be recommendable. Handling such data in an application, would warrant considering innovative approaches in implementing hosted solution- like a Multitenant/Multi-version hosted solution that uses separate Database Instances for individual applications. Such a solution ensures that all the clients get the cost-benefit associated with sharing of infrastructure; however, separate database instances ensure physical separation of data among the clients and providing requisite data security.
3. Is there a complex integration and interface requirement for the business function?
   Although 'On Demand' solutions do offer some interface/integration capabilities, they are typically not very strong in complex integrations. Straight forward, single business process automation can be very easily achieved by On Demand solution.  However, business processes involving interaction with multiple functions and applications, may require a complicated interface design, which is not easy to develop around an On Demand application.
4. Do I have a roadmap for enhancement, upgrade and maintenance for my IT Landscape?
   Challenges in enhancing, upgrading or supporting an On Demand application are quite different compared to that of a conventional in-premise application. Hence, it is important that decisions around On-Demand (or any application, for that matter) be taken after considering the mid-term and long-term roadmap, for these applications in particular and IT landscape of the organization in general. It is important to consider any upgrades and enhancements that could be planned for applications talking with the On-demand suites, since this may mean interface design changes. Compatibility of the higher versions of applications interfacing with on-demand solutions also needs to be accounted for. It may not be always possible to have a documented long-term roadmap in this ever changing business and technology world, however, its worth having it as a possible evaluation criteria.
   These questions merely give you a high level idea about pros and cons in going for an On-demand solution vis-à-vis an on premise solution. Needless to say,  this analysis  needs to be coupled with traditional 'top down' analysis- define the business processes, understand the underlying requirements and for these requirements, analyze the available options. After that you can put a dollar value to each option and freeze in on an option. Only then, can one choose an option that is a best fit - financially as well as operationally.

Posted by Guest Blogger at 6:17 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Ranjan Kumar Singh, Senior Associate Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Solvency is a measure of the risk an insurer faces of claims that it cannot absorb. Solvency has been a primary measure to gauge the health of an insurance company. Regulators in various geographies protect the policy holder's interests through Solvency norms and guidelines. It is a basic measure of how financially sound an insurer is, but this simple calculation that does not take into account the types of business the company does and the Risk that it is exposed to.

After formation of European Union the regulators introduced Solvency I framework which was used to monitor the Solvency of Insurers operating within EU. Solvency I was based on simple factors and formulas and was easy to implement. However with time it was known that the Insurers were facing many dynamic Risks from there day to day operations and simple calculations of Solvency could not meet the Risk which an Insurer was exposed to. It was decided to move from formulae based approach of Solvency to a Risk based approach and Solvency II framework was introduced.

Solvency II is the set of regulatory requirements for Insurance companies operating in European Union (EU). It is the proposed new legislation which will govern the capital requirements of Insurance companies within EU. Solvency II aims at setting revised guidelines for capital requirements and improves the Risk management Standards for Insurers. Capital requirements for insurers will be directly dependant on the Risk underwritten by the Insurers which in turn will be derived from consistent principals and models.

The proposed Solvency II framework has 3 main areas (pillars):

Pillar 1 is about Quantitative requirements which measure the amount of capital Insurers should hold. It measures the financial position and capital adequacy of Insurers by valuing its assets, liabilities and Capital.

Pillar 2 is focused on enhanced supervisory review of various processes adopted by Insurers. It sets out requirements for governance, control, Risk management and solvency self assessment of insurers.

Pillar 3 focuses on disclosure and transparency requirements. It consists of public disclosure of financial condition and solvency reports.

The following objectives explain the importance of Solvency II and why it should be adopted across the European Union by all Insurers:

1. To protect the interest of policyholders in European Union by ensuring the financial stability of (re)insurance companies.
2. To replace the age old Solvency I framework which was introduced in early 70s which defined capital requirements by blanket solvency margins which were quite simple in design and did not always reflected the true risk in a given portfolio of Insurance business.
3. To adopt Risk-based solvency system by aligning capital requirement of each insurer to the underlying Risk which it is exposed to.
4. The aim is not only to define capital requirement but it also requires companies to establish systems, processes and controls for Risk Management.
5. Use of Company specific internal model to calculate capital requirement encourages insurers to develop the risk management practices internally to correctly estimate the underlying risk.
6. To encourage increased focus on internal governance including identification, measurement, monitoring and control.
7. The set of regulatory legislations aims at providing a level playing field for all insurers within European Union irrespective of its legal form, size or location.
8. To improve the competitiveness of European Union Insurers both within EU insurance market and internationally by removing unnecessary regulatory constraints and adopting common set of rules for all.
9. To achieve consistency across European Union on key ideas like: Risk based capital allocation, Own Risk and Solvency assessment, higher accountability of senior management, higher Supervisory control and transparent reporting & disclosures.
10. Solvency II is based on principles and not rules so it provides an opportunity for Insurers in EU to really embed the principles into their corporate governance and culture so that business could be done in a more better and transparent way.

If you are aware of Solvency II and its importance then please do share your thoughts as part of comments to the blog.

Posted by Guest Blogger at 1:02 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

It has long been rife in the air, messages to be a socially responsible corporate. In the era of economic turbulence, organizations pan globe are looking at green initiatives, that have can have a deep impact from a social, environmental and financial standpoint. For an organization the financial and environmental impact of transportation improvement initiatives can be truly substantial.  Extending those initiatives beyond the enterprise can yield even greater improvements for the company and the community at large.

Within the four walls of the warehouse and organization, strategies such as load consolidation, move optimization, and shift in transportation mode from LTL to FTL or from ROAD to INTERMODAL, round-trip routing and optimized load planning can do wonders. These practices can lead to reductions in empty and circuitous miles, and also increased cubic capacity utilization. They can also lead to reduction in the number of vehicles required, reduction in net freight expenses and other operational efficiencies. And are they not GREEN initiatives? Sure they are. Reduced number of trucks directly implies reducing carbon emissions and fuel usage.

So what we are talking of here is a Responsive supply chain is also a Responsible supply chain, it is more environmentally and socially responsible. And at the end of the day it is also more financially viable. If these practices are extended beyond one's own organizations to one's trading partners, it can have a cumulative beneficial impact- the benefits will be manifold. I have read of many such collaborative initiatives such as; cross-enterprise continuous moves and collaborative capacity management. The opportunities for continuous moves and load consolidation are increased, the cost and empty miles are decreased, and the efficiency and productive turn of carrier fleets is improved. All in all it is a win-win situation from all perspectives: socially, environmentally and financially over a broad spectrum of participating community. The benefits of these improvements cross enterprise barriers and extend in to the greater supply chain.

Now let us look at the IT side of this paradigm. There are many best of breed and ERP warehouse and transportation management systems available in the market that can help achieve these results. Rate Shopping modules are widely available in almost all packages like Manhattan (Rate Shopping), JDA Software Services (Pfastship), High Jump's Warehouse Advantage (K-Ship) and Oracle Shipping execution that can help achieve and benchmark these transportation strategies. Oracle Transportation Management is also a widely used product to achieve load consolidation.

With clearly laid out carrier routing and load optimization policies, organizations can definitely achieve the three fold benefits of social, environmental and financial benefits. The operational levers of load consolidation and move optimization can result in tangible value levers of enhanced social, environmental and financial value. That is why organizations are looking to go GREEN. "Green really is the color of money", as they say!!

Posted by Amit Sinha at 4:58 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

In-memory computing is no more a new technology or terminology. There is always huge demand for real-time reporting that leverages real-time data and provides improved decision making capability by reporting from transactional and operational systems, minimizing the dependency on IT for reports when analyzing large data volumes. Performance always takes a beating in this process. This is where the in-memory computing comes into picture, promising immediate access to right information. The pace of business depends on how quick a reliable and smart decision is made based on the information available at that moment.

The traditional BI tools read the data from the disks while the in-memory products queries the data in  random access memory (RAM) ie. all the information is loaded in memory instead of the hard disks. As the data would be in RAM, the query response time would be much faster. The drastically improving hardware economics and technology innovations in software have brought adequate prominence among the Business Intelligence community, which has forced all major vendors to equip their stack with this armor - In-memory computing. Hardware innovations may include multi-core architecture, parallel servers, huge data throughput, increased memory processing capability, etc. The software innovations include row and column store, compression techniques, partitioning, handling aggregate tables, etc. When the solution comes at a lower cost, customers would obviously eye the options provided by various vendors and look at the other criteria such as performance, availability, interoperability, right fit of the solution into existing setup, etc. The focus would be more on pre-integrated analytic solution appliances. BI players like Microstrategy, QlikView, TIBCO Spotfire, Tableau Software already have made their mark. The biggies - Microsoft, IBM, Oracle, SAP, Teradata have a key role to play!

What are the advantages of having an in-memory appliance?

• Improved performance
• Optimal utilization of memory
• Low operating costs
• Reduced storage cost
• Improved efficiency

Why would organizations opt for an appliance based accelerator in an integrated analytical BI/data warehouse environment?
Most of the appliance deployments to date involve data warehousing. The reasons are quite obvious -
1. The ability to process high volume of data
2. Ability to report on high volume of data with good performance
3. Reduce the complexity of BI environment to make it operationally effective

Which scenarios would be the right fit for such a deployment?
* Need for a scalable architecture meeting organizational growth and ever growing BI requirements
* Significant growth in data volume on BI/DW environment
* Demand for more reporting functionalities across multiple business units

What are the tools to look out for?
QlikTech, Spotfire, MicroStrategy, Microsoft(powerpivot) but interesting to watch out for Oracle Exadata and SAP HANA.

Teradata and Netezza would be considered "fast databases" but are moving towards an appliance approach. The efficiency of these appliances can also be tagged to how customers can 'accelerate' their existing BI investments with an appliance.

Example of a future scenario: Oracle Exadata working along with SAP BW and reporting from OBIEE, SAP HANA as an accelerator on any database and any front end (not necessarily BO).

The future certainly looks bright & promising. In-memory technology in itself is NOT a driver of BI growth while it certainly cannot be ignored!

Posted by Sparjan Kote at 6:36 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Over the last decade or two supply chains have become increasingly complex. As large portion of manufacturing has moved from high-cost developed countries in the Western hemisphere to low-cost developing countries in the East, global trade has increased and so has the complexity of supply chains. Managing an increasingly complex supply chain requires availability of accurate and timely data to supply chain managers. Chain Visibility is a concept that attempts to achieve that.

Supply Chain Visibility is the capability to have (near) real-time information on the status of supply, demand, inventory, and capacity information across the entire supply chain. Supply Chain Visibility would involve:
* Having real-time visibility into status and location of goods in transit
* Having an accurate and close to real-time data about the demand from all the channels and customers
* Having an accurate information about future deliveries from suppliers
* Knowing accurately how much inventory is in the supply chain, and where exactly it is located
* Having a measure of current and future capacity utilization at manufacturing plants
* Having a visibility into the production status at outsourcers

Although end-to-end visibility of supply chain remains a utopian ideal, it is not always possible to achieve it in practicality. Hence a company needs to prioritize the areas where improving visibility lead to maximum return for the buck. For instance, a Consumer Packaged Goods (CPG) manufacturer might find maximum benefit in getting accurate information about real-time demand from retailers based on Point-of-Sale (POS) data. A component manufacturer might want to get real-time data about status of jobs that it has outsourced to sub-contract manufacturers. A retailer might benefit most by having accurate real-time information of incoming supplies into its Distribution Centers and stores from logistics providers.

Supply Chain Visibility comprises of two distinct features:
* Collaboration of data between supply chain partners providing real-time and accurate information across the supply chain
* Providing real-time event based alerts to supply chain partners that would enable prompt reactions to events & exceptions

A recent study by IBM found that Supply Chain Visibility was rated as the biggest challenge by largest number (70%) of Supply Chain executives across the globe. The study also found different programs being implemented by organizations for improving supply chain visibility. Some of the most common supply chain programs were:
- VMI implementations
- Collaborative planning with suppliers
- Collaborative Planning, Forecasting and Replenishment
- Continuous replenishment of material for customers
- Real-time sharing of inventory and demand data between supply chain partners

I would love to hear from the readers about their experiences while working on Supply Chain Visibility deployments.

Posted by Jayprakash Acharya at 11:38 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Rinku Das, Project Manager, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

With the introduction of Oracle Fusion Middleware technology, technical consultants who are mainly working on E-Business Suite started questioning how to expose Oracle business interfaces (like Business Events, PL/SQL, XML Gateway, etc) built using multiple technologies as Web Services and also how to invoke & consume external Web Services. The answer to such questions is YES. This is feasible using Integrated SOA Gateway available in Oracle E-Business Suite R12.1.

About Integrated SOA Gateway

Integrated SOA Gateway (ISG) is an integral part of Oracle E-Business Suite R12.1. With the support of SOA and Oracle Fusion Middleware, ISG provides integration infrastructure between service interfaces and loosely coupled applications. In other words, ISG is a framework which helps in the integration of end-to-end business processes. It also handles orchestration of native services, service security, grants roles and supports integration interface types like PL/SQL, Business Events, XML Gateway and so on. ISG allows invoking external services and also allows external clients to make use of the services provided by E-Business Suite.

Oracle has provided a repository called Oracle Integration Repository which will act as a centralized location where all service related business interfaces can be stored. Oracle Integration Repository is a console for service enablement and supports E-Business interfaces such as Business Events, PL/SQL, XML Gateway, etc. Using this repository tool, one can easily search for business interfaces which are required for integration purpose. Interface definitions are transformed into web services by administrators which in turn are deployed to the Oracle Application Server. These web services can be invoked from any web service applications.

Integration Repository administrator generates WSDL files for interfaces for external applications. Let's take Business Event as an example. Integration Repository administrator can create event subscription for business event in the event details page in the Integration Repository. An Out Agent WF_BPEL_QAGENT is created for event subscription. When an event occurs, the business event message will be enqueued in WF_BPEL_QAGENT and any external system can dequeue the event message from WF_BPEL_QAGENT using components like AQ Adapter for SOA Suite.

Oracle E-Business Suite Integrated SOA Gateway (ISG) uses framework called Service Invocation Framework (SIF) to consume and invoke web services. SIF uses Oracle Workflow Process to generate event messages to consume and invoke web services. SIF is a consumer whereas Integration Repository is a storage which transforms integration interfaces into web services which can be invoked from any web service applications.

For more information on Integrated SOA Gateway (ISG), Oracle Integration Repository and Integration Interfaces please refer to "Integrated SOA Gateway User's Guide Release 12.1"

Posted by Guest Blogger at 10:10 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Debapratim Dutta, Lead Consultant- Banking and Capital Markets, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

A few weeks back I woke up with the morning newspaper, and was surprised to discover that my sun sign has got changed! The news article explained that according to latest astronomical discovery there is now a 13th zodiac sign, instead of the long held astrological belief that there were only 12. The newly identified constellation which is between Scorpio and Sagittarius is called Ophiuchus. Before I could finish reading the entire news article, a friend of mine called up and sounding highly disappointed, informed me that from now onwards she will be happy to throw the morning newspapers' horoscopes in the bin. Co-incidentally, the day before that, the CRO of a reputed bank in an informal call told me, that from now onwards he will have to throw away many of the risk reports to the bin as most of the sophisticated risk models developed in the past are no longer accepted as valid by the regulators. Sounding equally disappointed as my horoscope savvy friend, the CRO wanted to know whether we can advise some solution to him, as they got to now re-do the entire risk data warehouse to cope up with new regulatory standards announced under Basel III.

Such news on failures of data warehouse projects in financial services institutions are not new. Limited understanding of end use coupled with exponentially increasing degree of uncertainty in the financial services space, makes the traditional approach in data warehouse design unsustainable in the rapidly changing regulatory landscape. Most often complex computational needs are not taken into account during design phase, resulting in ad-hoc delivery mechanisms for results. One primary reason for this is that, traditionally computation has been viewed as external to data warehouse thus making the model inflexible to future needs.  Moreover, need for excessive focus to address enormous ETL complexity in mapping sources to enterprise model deviates attention from the ultimate end use.

Thankfully, Oracle has recently come up with an innovative solution to counter flaws in traditional data warehouse design. The recently launched Oracle Financial Services Data Warehouse (OFSDW) readily deploys a pre-built, and end-use proven data model for Financial Services covering key analytical use cases for Risk, Finance, Compliance and Customer Insight. The OFSDW model maps every single attribute to its possible analytical end uses. In doing so, it considerably reduces the initial effort involved during data warehouse development by clearly focusing the exercise of mapping source data on its end use. Additionally, the OFSDW eliminates accuracy and consistency issues with thousands of pre-built data quality checks contextualized to financial services institution analytical end use and also eliminates inconsistencies across ledgers, books and marts through a formal and centralized GL reconciliation process for confident and fully auditable reporting.

Unlike traditional data warehouse design, OFSDW provides an analytical applications infrastructure which comes pre-integrated with 30+ Oracle financial services analytical applications and also can seamlessly work with third party or in house developed applications. The various components of OFSDW like the cube and mart builder, workflow engine, forms builder, statistical library, rules framework etc. provides a technologically advanced framework which can seamlessly adapt to unknown regulatory and business challenges of the future.

So even if the signs of zodiac keep on changing, with Oracle, you can always steer through uncertainty to your desired goals!

Posted by Guest Blogger at 10:00 AM | Permalink | Comments ( 1 ) | TrackBacks ( 0 )

Guest post by
Jaideep Ranjan Vijayakar, Principal  Consultant - Banking and Capital Markets, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

In the previous installment we discussed how to arrive at the effort estimate for the implementation team based on the complexity of the technical components underlying. These effort estimates can also be used to arrive at time requirements for the business IT counterparts (Business System Analysts and Business Technical Leads). We can pair them with their implementation team members and use a percentage of that effort. However we are missing a key portion of the implementation effort. BUSINESS TIME REQUIREMENTS.

The importance of estimating and allocating appropriate business resources at the right time cannot be understated. Many projects paint themselves into this corner by underestimating this time and not dedicating enough time on part of their business users to participate in design validation and testing phases. This result in either time overruns or compromises on quality as more is required to be done by less. It can also result in the project team working double/triple shifts in order to meet deadlines causing tremendous stress on all concerned.

In our recent implementation we faced similar pitfalls and realized we needed to come up with a guideline that the Global Process owners could use to estimate the time requirements of their SMEs. This requires breaking down the overall implementation project into its component phases and guestimate the typical effort required to be spent by business users in each phase. This guestimate can be hours per day during testing or CRP period or %age of IT time during requirement gathering and design review period. This is what we came up with which helped the business staff the critical phases of the project with the right people by hiring temps, moving resources between departments or re-prioritizing day to day activities.

Month	Implementation Phases	Business Participants	Activities	Time required
Sep-10 Oct-10	·Requirement  Decomposition ·Functional Design ·Technical Design ·Development	·Global Process Owner (GPO) ·SME	·Provide Business Requirements ·Review BRDs ·Review Fit/Gap Analysis ·Review FDs ·Prioritize and Approve Additional Requirements ·Review Specifications for Data Migration	·2-6 hrs per day each ·1-2 SMEs per GPO
Nov-10 Dec-10 Jan-11	·Configuration ·Technical Design ·Development ·CRP	·Global Process Owner (GPO) ·SME	·Review Configuration Docs (BR100) ·Review Conversion and Data Migration Strategy ·Review Training Plan	·8 -10 hours per week each ·1-2 SMEs per GPO ·Additional Time would be required during CRP period- 4-6 hours per day
		·Application Owners	·Provide Inputs for Functional Configurations ·Finalize Configuration Docs (BR100) ·Provide inputs for Data Mapping for Conversion ·Finalize Conversion Routines ·Provide clarifications for Technical Design Team	·2 -4 hours per day each ·1-2 Application Owners per GPO ·1-2 SMEs per GPO
Feb-11 Mar-11 Apr-11 May-11	·Testing and Deployment ·Training ·SIT ·UAT ·Cut Over ·Go-Live	·Global Process Owner (GPO) ·SME	·Participate in UAT ·Sign Off on Configuration and RICEWP Components ·Sign Off on Training Plan and Documents ·Participate in Cutover Activities ·Go-No Go Decision	·2-6 Hours per day each (time required increases from Apr-11 during UAT and Cutover- 6-8 Hours per day)
		·Application Owners	·Participate in Data Migration Testing, SIT, UAT ·Undergo Key User training under the "Train the Trainer" approach ·Validate Cutover Data	·1-2 FTEs per GPO ·(time required increases from Mar-11 for Training, SIT, UAT and Cutover 6-8 Hours per day)
		·Project Resources	·Participate in Data Migration Testing, Functional Testing, SIT	·1-2 FTEs per GPO

Depending on the amount of information we have about the project implementation plan upfront, while initiating the engagement, it's even feasible to consider incorporating the table above in the SOW (or at the end of Discovery) to indicate Client Responsibility towards the success of the implementation. Again the table is still work in progress and we are still in the process of coming up with the best possible way to estimate this time and effort. It could be possible, based on empirical evidence from the vast number of engagements that are executed by SIs and through pro-active data capture we could generate "Estimate factors" which could be used to provide realistic "Business Time" requirements to the Client from the word go. Please send in your comments and responses to the above and let me know if you have any ideas or strategies that could be used for this.

Posted by Guest Blogger at 1:28 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Prasad Jayakumar, Technical Lead, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Early morning I was hitting I-94W to meet my client in Milwaukee.  I wish I had my I-PASS; toll varied from 25 cents to little more than a dollar.  I was wondering "Why not the government builds the infrastructure out of tax collected and let us free?"  Immediately I realized my ignorance.  My discussion topic with client was "How to measure ROI for SOA Projects?"  It was a meeting to see if we can present benefit of SOA in a tangible way to business.  I was wondering if the toll way could answer the question.

 

Please note: All values are notional. Click on image to enlarge.

 

The whole idea of SOA ROI by toll way approach is based on Throughput Accounting. 

Throughput (T) = Daily transactions priced at some notional $ value

Investment (I) = SOA Infrastructure Setup

Operating Expense (OE) = Development Cost + Maintenance Cost

Return on Investment = (T-OE) / I

There could be a day where IT paybacks some business unit (Service Provider), of course getting from other business unit (Service Requester).  What else could motivate business better than dollars?  I am not sure if business would be interested on asset/service reuse [it is presumed to be IT thing] unless we position it differently.  Tollway approach can go beyond measuring ROI if embraced by business and IT.

Posted by Guest Blogger at 11:31 AM | Permalink | Comments ( 1 ) | TrackBacks ( 0 )

"Oracle Fusion Applications are built using industry standards-based Java middleware, and integrated with business intelligence, not just process automation," - that was Larry Ellison highlighting 'history making' innovations from Oracle stable during this year's OOW.

Oracle started consolidating in the BI space sometime in 2005. My guess is that was the time when Oracle would have envisioned a lot of confusion down the line with multiple products increasing chances of cannibalization. This was also the time when BI space was seeing a lot of volatility with organizations increasingly tilting towards pre packaged BI solutions and pushing vendors to pack in advanced BI features like forecasting, kpi tracking, visualization etc.

In keeping with both these factors, Oracle has carefully crafted a roadmap with dual purpose of creating a product suite to cater to both epm as well as bi needs and with this varied arsenal it plans to meet the ever changing demands of epm space.

Oracle is enhancing its core reporting platform, OBIEE, to 11g which seamlessly integrates with all leading OLTP as well as OLAP platforms. It includes score carding abilities which were previously absent and also is backbone of BI Applications suite. Oracle Essbase and Oracle OLAP form the multidimensional analytics pillars for planning, budgeting, sales helping identify key trends and boosting business decision making. On enterprise performance management part, Oracle has solidified its presence with acquired hyperion products like strategy management, profitability and cost management,planning budgeting and forecasting apps. These are complimented by other oracle products like crystal ball, DRM, IR etc to create the most comprehensive BI offering from any vendor as suitable acknowledged by all leading analysts.

Fusion applications makes BI and integral part of ERP and is a clear indication that Oracle will keep refining its magnum opus following it's well led out bi roadmap.

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

Often BPEL based Integration projects will have requirement to connect to existing enterprise applications resources, such as Java/J2EE resources.  Oracle BPEL process manager offers Web Services Invocation Framework (WSIF) which allows BPEL processes to access external resources natively. WSIF requires no modifications or extensions to BPEL code and makes BPEL more suitable for enterprise application integration.

Features of rest:

• Resources are identified by uniform resource identifiers (URIs)
• Resources are manipulated through their representations
• Messages are self-descriptive and stateless
• Multiple representations are accepted or sent
• Hypertext is the engine of application state

Advantages of rest web services:

• Lightweight - not a lot of extra xml markup
• Human Readable Results
• Easy to build - no toolkits required
• Consumption of rest web services is easy. They do not carry SOAP headers.
• Rest Web services are highly nested.
   

Limitations of calling rest services using BPEL:

• BPEL cannot invoke Rest based service using PUT or DELETE methods. BPEL supports only GET and POST methods.
   

Rest based service calls in SOA/AIA:

In SOA/AIA, we can send xml messages through a rest based approach. Unlike, our normal way of sending SOAP messages, rest based approach allows BPEL process to send/receive xml messages over a HTTP url. These messages posted over the HTTP url are not SOAP messages.
 
BPEL process receives HTTP requests from external application : This approach can be used, if we want a BPEL process to be invoked from a client that is not web service centric and can use only HTTP requests to communicate. In order to receive messages through HTTP requests, we are supposed to use HTTP bindings in the BPEL process wsdl rather than SOAP bindings.
 
HTTP bindings would help to describe the interaction between a Web Browser and a web site using HTTP GET and POST operations. The following protocol specific information need to be specified:

• An indication that a binding uses HTTP GET or POST
• An address for the port
• A relative address for each operation (relative to the base address defined by the port)

And with this, we come to the end of my brief discussion on How to Extend BPEL Integrations with WSIF. Do feel free to send in your comments.

Posted by Anu Samantha at 3:47 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

I was reading up on clouds and their drawbacks and one issue that kept repeating was customers loosing control of their applications and data to the cloud service providers. One of the key themes of Cloud computing is to scale the computing infrastructure on the go as well as pay for only what you use. So i was wondering if it is possible for customers to use the cloud only for scaling their existing computing infrastructure without moving their entire application to the cloud. As i read more on this problem, I stumbled on a new concept (new for me :-)) called the "Hybrid cloud".

The whole concept of the "Hybrid cloud" is that the Enterprise maintains some instances of the server running the application on-premise while the scalable instances are available on the cloud on virtual machines.

The obvious benefits of the above approach are similar to the benefits of a full fledged cloud implementation-
1. Pay for what you consume
2. Get scalability - both upwards and downwards without huge investment in infrastructure.

But in addition to these points, the key benefits of the Hybrid cloud are -
1. Maintain control on your existing application and data. No need for expensive re-engineering or moving the entire application to the cloud.
2. Reduce dependence on cloud service provider as both application and data continue to exist within the Enterprise.

But the Hybrid Cloud solution does come with its share of challenges.

1. Security - Transactions are still being processed outside the Enterprise, so adequate care has to be taken to address security concerns
2. Management- Because the cloud provider may not know much about the application that the enterprise is hosting, application management will require close co-ordination as well as more enterprise access for the cloud instances to resolve issues.
3. Responsibilities - because the application is owned and managed by the Enterprise with the cloud provider only providing the infrastructure, clear identification of responsibilities for issue resolution need to be arrived at.
4. SLAs need to be clearly articulated

From a technology perspective Oracle Weblogic Server - WAN clustering seems to be an ideal fit for the Hybrid cluster. This technology supports clustering and asynchronous session replication across 1000s of miles. It is a robust solution and already widely used in the Industry. Instead of using this technology to build a cluster between two data centers of the enterprise, this same technology can be used to cluster the enterprise data center with cloud instances.

The key application of the Hybrid cloud according to me will be for seasonal applications e.g. Travel booking web sites, Retail web sites, University websites are some of the applications which require peak computing power only during some specific times of the year. The Hybrid cloud allows these Enerprises to maintain control on their applications as well as allow them to scale during these peak times.

 

 

Posted by Satyajith Nair at 9:16 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Social CRM has been one of the top trends that have been witnessed in the CRM space in recent times. As per a study by Gartner Research, by 2013 the total investment in Social CRM space would exponentially increase to around 1 billion dollars, about 8% of the total CRM spending. In Social CRM the customer sits in center of the CRM processes and is an active influencer in business decisions. The customer and organization constantly interact and collaborate in order improve the customer experience. In return, the customer becomes an advocate of the organization highlighting the work done by the company. Social CRM is not just about bringing the customer in the center of the processes but it requires a change in the strategic outlook of the organization.

Social CRM can help insurance sector to leverage from this upcoming trend. For example:

• Allowing today's social media aware customer to interact directly with insurance companies without the presence of any middle layers or agents. This is possible using the concept of online communities
  
  
• Increase the brand visibility by using the communities of "like minded" people
  
  
• By monitoring the online communities of other brands/carriers, insurance companies can target new potential clients Insurance companies can increase customer's awareness and help them by providing tips on how to avoid certain dangers that can lead to claims being turned down
  

As many sectors are embracing for this change, Insurance sector can also reap huge benefits by moving in to the era of Social CRM. The massive amounts of data that will be collected using social media channels can be analyzed and used in different processes of insurance industry.

But as we talk on role of social media in insurance sector, one must realize that Social CRM as a concept in insurance sector is still in a nascent stage and definitely seems to be carrying a huge latent potential that can be used in different dimensions of business processes. Only time would tell that how fast and efficiently insurance sector gauges on to this trend.

Posted by Rohit Kaushal at 4:41 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Nobendu Roy, Senior Project Manager, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

We know that LSH is a clinical data integration platform, but it can also be used as a computing environment that gives tremendous power and flexibility to a PLSQL programmer to extend the functionalities.

I can take an example of safety analysis and reporting which are a part of any safety package: Argus, Phase Forward Emperica, ARISg etc. If a client has LSH and doesn't want to invest on a safety system then will that prevent the client from performing pharmacovigilance analysis? The answer is a big "NO" because LSH can be configured to address drug risk analysis and signal detection. The power of LSH lies in its set of load set adaptors which can easily be leveraged to load and transform the necessary data sets in its data repository. Moreover OBIEE also comes bundled with LSH and hence it is easy for a PLSQL programmer to develop the programs to generate the risk analysis and signal detection graphs and reports in OBIEE. It is all in the hands of a PLSQL programmer.

I intend to publish a series on the power of LSH based on the inputs provided by the readers and the discussion that shapes up over a period of time.

Posted by Guest Blogger at 11:41 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

In today's world, many of ERP Implementations are large involving multiple regions, countries and businesses around the world.I am talking about large multinational corporations which have foot prints around the world either directly or through subsidiaries. Some of these corporations also have grown bigger through mergers and acquisitions.

Another characteristic is some may have many sub divisions which act as separate companies under single parent company.Many of my Oracle implementations have always been global implementations. Sharing some of the challenges faced in the order of severity.

1. Global business modeling: - Bringing them in single business model is never easy. Though the project is by the IT organization (implementation of Oracle) but it some times goes into BPR mode involving all the business leads in all regions/divisions to align business process

2. ERP landscape and strategy decisions: - These are tough decisions involve which legacy system to be retained or retired. For example a newly acquired business is not willing to change their system since they have already implemented another ERP System.

3. Continuing to above point, Single or Multiple oracle instances is always a big question.

4. Managing master data across multiple regions. I have seen establishing this as one of most difficult process.

5. There are external factors impacting schedules and budgets. There is new acquisition or new business/region in scope when the global modeling and design is over.

6. Diversity - Each region could be different by business and volume of business. For example North America region might have large order volume where as Asia order volume is less though majority of sourcing and manufacturing is done from Asia.

7. Just adding to above point the number of people involved can be different by region n business process. One region - it could be one person managing entire purchasing process

8. Regional Requirements: There are additional requirements and global business process will not fit because regulatory issues at some regions

9. Requirement complexities ,  the requirements also get complex which an overlap and map across multiple business functions and modules

10. Coordination and communication across all the regions is always difficult because of the locations, time zones. Adding to the above are cultural issues and language barriers

Well the list goes on. Also want to mention challenges (risks) project management angle.

 
a. Planning for long term with huge budget and the benefits are not immediate
b. Hitting unexpected economic situations, such as economic slow downs. If this hits during middle of the implementation. Risk of abandon/holding the project will be putting money and effort in the drain
c. Getting the resources engaged to work

So well you all read the pains, some of this pains were reduced from implementation level through below.

1. Having global design team (central) which will gather requirements from each region and own the solution design
2. Mapping regional requirements to create common global process and design.
3. The regional team or rollout team will be responsible for tailoring global design and roll out to meet regional requirements and deviations needed
4. Once Single or multi instance (it is whole separate discussion) decision is made, identifying business process which map across multiple instances.
5. Same goes with if some of the regions or businesses decide to retain existing ERP/legacy applications. Laying down business flows across systems and identify data exchange interfaces as applicable
6. Coordination is another topic which needs separate discussion. With global conference and screen sharing tools definitely help the discussions. Some amount of traveling is always needed. Setting common time for discussions is something needs to be worked depending on the flexibility by the teams. I worked late nights and early morning to fit other time zones
7. Handling complex business scenarios across cross tracks/business has been done multiple times by us by having cross track discussions and doing handover/take over process. These cross track flows will be taken till the end by having cross flow testing scenarios and requirement traceability tools so that they are not missed.

Though I have mentioned some challenges and how these were met. Every implementation is different and it has its own challenges apart from the above. 

It might look like crossing a sea which reminds me of inspirational quote from Holy Bible "Thus says the LORD, Who makes a way through the sea And a path through the mighty waters"

Posted by Ramesh Pusunuru at 7:14 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Jaideep Ranjan Vijayakar, Principal  Consultant - Banking and Capital Markets, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

As they say "A journey of a thousand miles begins but with just one step" so too any Implementation project begins but with its estimation. Many a project flounder due to inaccurate estimates made to start with. Without an accurate estimation of effort and timeline it's difficult, if not impossible, to allocate the correct resources to the project or determine milestone dates and phase durations.

Typically most IT companies drive their estimates from the technical components that need to be developed as a part of the implementation. There is a wealth of data available on the time taken to develop components based on the complexity (SMC) and type of component (RICEWP). This is similar to the Function Point or LOC approach to estimation.  However this does not take into account the time and effort spent in getting the business requirements to a stage where the Functional Designs are ready to begin the technical effort. We are able to estimate the technical effort and staffing fairly easily but struggle to understand the Functional Effort or System Analyst effort that is required to support the development.

To ensure that the efforts are comprehensive we need to take a comprehensive look at the following activities that make up the development lifecycle.

1.Requirement/Proof of Concept/Analysis

2.Functional Design

3.Technical Design/Build/Unit testing

4.Testing (SIT/UAT)

5.Config/Implement

7.Performance Testing

8.Regression Testing

DBA

Project Management

Now providing estimates for each of these activities is not an easy task. However a simple way to arrive with a ballpark estimate is to base the effort on the core development piece around which these activities are centered. The complexity of the development component can be a proxy for the effort required for the requirement gathering, testing and other activities. This may not be true in some cases but at least it can be used as a benchmark, which can then be tweaked if required by the project managers for variants.

Another way to arrive at estimates for the Requirement analysis and Functional design phase is what I call the Recursive Meeting approach. This considers the complexity of the business processes which are being solutioned for and factors in the number of meetings, revisions and reviews that would be required to freeze the requirements and functional designs. It also tries to understand the Key Stakeholders/Participants required at each step of the process. Typical participants are Global Process Owners, Subject Matter Experts, System Analysts along with the Process and Functional Consultants. By providing estimates of average meeting time for each revision and guidelines on how many revisions would be required based on process complexity we can arrive at effort estimates required to decompose requirements down to the component design level.  The table below gives an indicative view of this approach.

Step	Step Details	Participants	Sample Duration*	Comment/Output
1*	Decomposition of requirements	Global Process Owners, SMEs System Analysts Process Consultants,  Functional Consultants	0.5 Days	Step 1-3 is an Iterative Process till Requirements Finalized   Sample Iterations Estimates 3  Iterations for Simple 5 Iterations for Medium 7 Iterations for Complex
2*	Document Details from Step 1	System Analysts Functional Consultants	0.5 Days
3*	Review Requirement Documentation	Global Process Owners, SMEs System Analysts Process Consultants,  Functional Consultants	0.5 Days
4	Analysis of Requirements- High Level Fit Gap	System Analysts Functional Consultants	2 Days	High Level Fit Gap Analysis
5	Confirm Fit Gap Analysis	Global Process Owners, SMEs System Analysts Process Consultants,  Functional Consultants	0.5 Days	Confirmed Fit Gap Analysis
6	Determination of RICE components	Global Process Owners, SMEs System Analysts Process Consultants,  Functional Consultants	1.5 days	Draft List of RICE Components
7	Confirm RICE Components	Global Process Owners, SMEs System Analysts Process Consultants,  Functional Consultants	0.5 Days	Confirmed List of RICE Components
8	Prepare Functional Design Documents	System Analysts Functional Consultants	Depending on Complexity	Functional Design Document

 

In the next installment we will discuss a more critical aspect of the estimation process - how to estimate Business Time Requirements.

Posted by Guest Blogger at 9:47 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

With RAM memory cost decreasing drastically, a new kind of computing paradigm is in the offing. Server Systems without Hard-disks may not be far-off.

Disk-based computing is fraught with performance and management issues and doing away with Disks though not practical now, maybe true in the future. This also calls for a re-think of our current application architecture which is so focussed on disk-based persistence.

Coherence the In-memory data grid from Oracle is one of the futuristic solutions that seems to ideally fit this gap. Coherence provides an in-memory data caching service which can also be clustered across several servers. In effect, Coherence provides a capability to store application data in Memory (RAM) clustered across different servers. It takes care of backing up the data across several nodes as well as a robust indexing mechanism to quickly access the data. It also supports  massive parallel computing capabilities allowing application logic to execute on the data in the data-grid in parallel.

As cloud-computing taking root, it becomes imperative for getting the maximum performance from the cloud-hosted application with the minimum investment in infrastructure. Coherence will allow the cloud application to access data quickly from the RAM instead of going to the Disk, thereby improving performance by several orders of magnitude. The coherence solution is resilient to data loss as it maintains a backup of the data on other nodes in the cluster.

Theoretically, the entire cloud application can be built using Coherence as the data persistence layer. In practice, the disk storage will still be required from a reporting and enterprise data storage persective. But the moot point is that the role of disk storage as it is used today is set to reduce drastically.

More and more transaction oriented processing will happen on the coherence grid with write-back setup to store data offline to disk storage.

Thus Coherence is set to become one of the most important technologies for building the next generation Cloud Application.

Posted by Satyajith Nair at 3:53 AM | Permalink | Comments ( 2 ) | TrackBacks ( 0 )

It has been debated over and over again if Best of Breed WMS is more suited to lower the Total Cost of Ownership as compared to an ERP based WMS. But a settlement has not been reached yet. Organizations with logistics management as their core competency may choose to favor best of breed software whereas a traditional sales company or retailer may choose to look in the other direction.

ERP-based WMS solutions are gradually making inroads into this terrain but they are myopic in terms of classical warehouse operations including receiving, put-away, inventory control, picking and loading. Warehouse operations entail much more and beyond these set of identified functions like labor management, slotting management, advanced wave planning, and last mile delivery. These operations are generally not solutioned for or supported by ERP WMS solutions. And if the need arises to have these capabilities built in, the same would have to achieved via expensive customizations with multiple integration touch points.

It has been said a general rule of thumb that a WMS solution typically has a life span of approximately ten years. ERP upgrades are generally more expensive because of the interdependencies between modules and re-application/reporting of customizations. This too gives a lean towards the best of breed WMS software.

A traditional ERP boasts of the following features:

• Lower Integration cost: upfront as well as over a period of time
• Functionalities that is good enough for simpler operations
• Less Vendor risk due to larger company size

Parallely Best of Breed WMS boasts of the following features:

• Superior and best in class functionality
• Focused on supply chain operations
• Complete Logistics suite supported
• Vertical Industry experience

Both claim to lower the total cost of ownership. The search of truth is on and the right answer lies with the SMART organizations that know what they really need.

Posted by Amit Sinha at 3:40 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Ravisankar Nagavarapu, Technology Lead, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

In today's world most of the organizations are going for complex integrations of heterogeneous contents on their websites. This is resulting in scattered web content and scattered information is very difficult to manage and maintain.

Oracle Service Oriented Architecture (SOA) and Oracle Portal Life cycle management make it easy for the developers/organizations to bring heterogeneous content from different web assets on to a single platform. The open nature of the architecture and the standards provided by the tools help organizations to plan their future for rationalized web assets.

Major reason for web assets' proliferation

In the initial days most organizations made lot of investment in getting their own web sites for different purposes, which resulted in web assets' proliferation. Below are the major pain points which drive the rationalization of the web assets:

• No unified view of organizations' information
• User interface (UI) being inconsistent
• Multiple security mechanisms
• Little re-use and code sharing

Approach to avoid web assets' proliferation

Rationalization is an incremental process with Oracle SOA and Portal technologies. But it can make the applications to be more efficient and cost effective very quickly.

There are different ways to go towards rationalizing the web assets:

• If an application requires more than 75% of re-work then write it as a service to be delivered through portal platform.
• Access to any re-usable application has to be routed through the portal platform.
• New services are developed as native to Oracle Portal.

Leveraging Oracle products to overcome the pain points in rationalization

• Oracle Identity and Access Management (OIAM) suite provides a rationalized security for the tightly integrated portal platform.
• Re-usable UI elements of Oracle's Web center suite such as skins, skeletons and themes can be leveraged at the master portal which can be inherited to sub portals.
• Oracle web center suite provides a frame work that can be re-used by leveraging which, the organizations can avoid re-writing lot of code.

Posted by Guest Blogger at 8:39 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Many organizations ask them selves 'how do we design our last chart of Accounts to last for the next 50 years' The fact that it is almost impossible to predict future management and financial reporting over such a long time frame. One approach is too look at pains of the current financial and management reporting system and identify the root cause of the issue. Often times it may be a result of change in business direction that could not be adequately be represented in the chart of Account structure.

For example at one time Banking companies had limited products catering to retail and corporate customers but today you have complex products like derivatives and currency swaps due to globalization. Banks offer various sales channels like "In Branch", "On Line services", "Agent driven services" etc.Over time last 15 years, the internet has given rise to completely new channel of selling. A bank today without business channel segment
would have a difficult time determining profitability by channel. This would lead to expensive workarounds or inadequate reporting or both. The issue could have been avoided with some foresight to add a future segment to the structure. If the bank had a future segment, it could have been redefined as a channel or product segment when the need arose. Other examples where a future segment is useful is when a company expands from one product line to multiple product lines. Consider Oracle when it was once a database company. It now boasts several product lines. 
The above examples demonstrate that changes in business direction over time are completely unpredictable.  Therefore the leading practice is to define two alphanumeric segments as future segments in your existing chart of accounts

Thus Future Segments in a chart of account are an insurance policy to be able to provide complete, effective financial reporting information even in the face of major changes in Strategic direction

Posted by Sachin Chitlange at 3:21 AM | Permalink | Comments ( 2 ) | TrackBacks ( 0 )

Primary objective of ERP Deployment is to provide a strong foundation and drive the standard business processes across the enterprise. It is time to retrospect and check if this is really required or happening? Can various business divisions drive their processes in a single installation and induce variation in design? What would be the best approach if processes are to be improved on a continuous basis? Say one division implementation to other division implementation The global design of business processes vary based on
• Nature of the operations and processes
• Local statutory / legal requirements
• Limitation of technology at the time of deployment
• Availability of standards
• Knowledge of the consultant who designed the processes
Even if the nature of operations is same, we are now seeing a variation in business processes from one division to other division. This means that there is more than one process to meet the same business requirement within the same installation. These processes will have their own merits and demerits. Once the implementation is completed and project is transitioned to support, the support analyst needs to understand more than one business process for the same business requirement.
There arises a question in the minds of the support analysts why there is a variation in process design? Can't we have the same business processes for the same requirement? The debate can continue for any long without any answer. This variation in the design can be called as evil and no one like to have the same at the time of initiation of the project. But by the time the project goes live the new design is evolved, resulting in multiple processes for the same requirement.
What is important to understand is that this kind of variation is good for global enterprises as one need not have to carry forward the inefficient processes designed in the early stages of deployment to the later stages. By this way enterprises can be more efficient. Imagine a simple purchase process of direct material was designed with 10 steps and 25 clicks as part of the global design. The same has been achieved with 8 steps and 20 clicks subsequently. Should we consider the later process or continue the former one for the subsequent deployments? Going with later process will result in design variation and going with former process is carry forwarding the inefficient process.  One should also think of re-deploying the improved processes to existing business divisions and 'drive-in' continuous improvements. Does this answer why an evil is required?

Posted by Murali Krishna Somisetty at 12:14 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )