Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« January 2012 | Main | March 2012 »

February 20, 2012

Managing Disruptions in a Project Driven Supply Chain

In the recent years pangs of supply chain disruptions have been felt by almost every industry. Devastating Tsunami in Japan and severe flooding in Thailand in 2011 had crippled Automotive, semiconductor and electronics Industries - the ripple effect was far reaching, it impacted every strata of supply chain. Enterprises came under the assault of significant supply shortages that led to lost sales, missing revenue targets and left the consumers high and dry. Besides natural disasters, supply chain disruptions may stem from various reasons such as political uprising, security breaches, or simply financial meltdown of key supplier(s).

 In a project driven supply chain, where OEMs provide both equipment and installation services the problem is further compounded due to interdependence between project plan and supply chain plan. The tighter both the plans are integrated, the better prepared is the OEM to withstand the disruptions. Identification of critical path and assessing the feasibility of meeting milestone dates are key aspects of project planning. Generally delivery of key components/equipment is mapped to milestone dates in the Project Plan. When disruptions occur supply chain planners would immediately publish the information about delayed supplies from supply chain planning system to Project planning system and alert project planners to assess the impact in the project plan. In the event delays eat up the float available in the plan, project planners may seek alternate option from the supply chain planners. Such interactions could happen back and forth and it calls for a seamless integration between Project Planning system and Supply Planning system.  Besides collaboration capabilities supply chain planners will require rapid simulation capabilities to identify alternate sources and transportation options.   Meeting the due date is not the only criteria that the planner checks, he/she needs to evaluate and choose the most cost effective option as well. Further to absorb and buffer intensity of disruptions, supply chain planners may evaluate the level of safety stock and inventory optimization strategies (refer to my previous blog on Inventory Postponement).

It wasn't until recently that the supply chain practitioners and strategists realized the importance of building resilience in the supply chain.  Underlying IT solution plays a pivotal role to create and foster a resilient supply chain. A well designed and developed IT solution can provide conduits for collaboration and information sharing, rapid simulations, and Business Intelligence to quickly recover from the disruptions.

February 19, 2012

OBIEE 11g Upgrade - Some Key Considerations

Guest post by
Karan Chadha, Associate Consultant, Infosys


OBIEE 11g was launched amidst much fanfare in mid 2010 and the feedback since then has been fairly positive. Owing to this success, the market is seeing a lot of traction towards OBIEE 11g upgrade. I was a part of one such upgrade project and based on my understanding I am sharing a few key considerations:

  • Why should an organization upgrade to OBIEE 11g?
  • How automated is the upgrade and how much of manual effort is involved?
  • What would be the tentative timelines to complete the upgrade?

Why should an organization upgrade to OBIEE 11g?

The superiority of OBIEE 11g is primarily on three accounts. First, it has a more robust architecture employing Web Logic Server and Fusion Middleware Control leading to improved scalability, performance and administrative ease. Second, it offers a host of powerful features like Scorecards, Action Framework, Geospatial Analytics and integration with iPad/iPhone making it one of the most comprehensive BI suites in the market. Third, it offers richer and enhanced visualizations leading to better user experience.

Despite a long list of benefits that OBIEE 11g has on offer, it is critical not to jump to an upgrade. The key is to have a thorough evaluation of the new features of 11g against the strategic objectives and BI usage patterns of the organization. This will help in determining the benefits that business could expect out of an upgrade. With OBIEE 11g upgrade being effort and cost intensive, this evaluation will ensure that a valid business case is proposed and an organization's return on its BI investment is maximized. OBIEE 11g upgrade may be inevitable at some stage but not obvious right away.  

How automated is the upgrade and how much of manual effort is involved?

The upgrade utility that Oracle provides upgrades the RPD and the Web Catalog automatically. Anything lying beyond these two components requires a manual upgrade. Some key components which fall under this category are:

  • UI Components like Banner, Logo, Brand line and font to name a few are driven by CSS and HTML files which lie beyond the RPD and Web Catalog. Copying the content of these files from one version to another is also not feasible since the structure of these files is different across versions.
  • Various Configuration Tags in InstanceConfig and NQSConfig files are also required to be manually added or modified and copying the content across versions is not feasible, again, due to the difference in structure of these files in both versions.
  • Other Miscellaneous Components like Clustering, Scheduler Schema (requires configuration in Enterprise Manager), and Custom Messages also require manual intervention.

Prima facie, it might seem that the upgrade is predominantly automated. But the seemingly automated portion involves a lot of manual effort primarily due to two reasons. First, OBIEE 11g being structurally different to 10g leads to certain aberrations (for instance, the new charting engine employed by 11g necessitating rework on several graphs or certain metadata warnings in 10g becoming errors in 11g). Second, the upgrade process is far from perfect resulting in defects and anomalies. The corollary of the second point is that extensive testing is required to ensure all objects are working the way they should. Taking these factors into consideration, a lot of manual effort is required especially to upgrade a complex environment.

What would be the tentative timelines to complete the upgrade?

The timelines could vary from just a couple of days to 10-12 weeks depending upon the complexity and size of the environment. While upgrading a vanilla 10g environment with the default 'Paint' RPD may take only 1-2 days, upgrading a complex environment could be a 10-12 weeks job (considering a 3-4 member team). To sum it up, the timelines will depend on the number of subject areas, reports and dashboards, number of new features configured, level of UI customizations, and the overall complexity of the environment. A 2-3 day assessment exercise of the environment should give us the answer.

Thinking beyond Hyperion Essbase for planning (Part 2)

Guest post by
Hari Ram, Senior Systems Engineer, Infosys


In the previous part of the blog, I discussed about the basic differentiators between Essbase & Hyperion Planning based Financial Planning systems. In this I am sharing thought on Data and Process management aspects of both the approaches.

  • Version management
    In Hyperion planning, the Version dimension, which is one of the default dimensions, can have two members of either a Standard Bottom-up or Standard Target type. The Standard Bottom-up allows users to input data only at the lowest level of members, while the Standard Target allows users to input data at any level of members.

In Standalone Essbase based planning system, a Version dimension may be created to handle different versions of data (In Progress, Frozen, Approved etc..,). The different versions don't have any built in features to handle Bottom-Up or Top-Down planning.

  • Data validation at entry level
    Hyperion planning provides the inherent data validation rules feature that can not only highlight the deviation of data from the guiding rule, but also reflect the same in the Approval process. This not only gives better visibility of deviation, but also keeps check on the data-integrity and track of problem areas. The turn-around time for an additional look at the situation is reduced due to the single-standard, single view of Data Forms, approval path across the users.
  • Handling task calendar
    Financial Planning process would involve a series of activities and processes and change of ownership, beginning from the data load from a transactional system. In many cases, where Hyperion planning is not the Financial Planning system,  the individual tasks, activities, ownership, due dates, status are tracked either in a customized MS Excel spreadsheet or another web-based portal.

Consider a Calendar tracking system based on a web-portal. The Calendar would have-
•   Option to create tasks.
•   Assign ownership
•   Select the due date
•   Option to update status of tasks.
•   Links to the standard Excel based data entry/reports spreadsheets

One has to traverse from the Calendar tracking portal to the data entry excels and then connect to Essbase to work with data. The loose-coupling/dependent -yet so alien relationship (a very bad combo) between the underlying code of the Calendar system with the Data repository (Essbase) poses a major threat to the very thought of enhancing the approach. The rigidness of the existing Calendar tracking application and the effort of coding the portal or making the enhancements to the legacy approach do bring in a road-block due to time and money involved with it.

I have seen few Task Supervisors maintaining Excel based Calendars to track the status of tasks during the Financial Planning process. It sounds so risky & unmethodical.
The Hyperion Planning Task List provides a tightly coupled, single box relation between the Calendar tracking system and the Database and Data Forms. Enhancements or change in approach can be seamlessly brought-in without much hassle.

  • Approval process
    The approval process is handled either through conventional mails or web-based portals built outside Hyperion family.  Hyperion Planning brings the comfort of having a comprehensive box to handle data ownership and promotion towards approval. Also, the centralized view keeps the user community informed of the status and bottle-necks along the data movement/approval process.

I used to work with a standalone planning application, where data would be moved to relational database through a web-based portal for data approval and then transferred to another application for Head-Quarter view. Handling approval process for multiple entities was a challenge due to rigid coding of the Java based portal working with PL/SQL. After lot of brainstorming, we had to give up the whole idea of multiple entity promotion due to additional effort and chances of violating the standard approach across the Organization.

The Planning unit Hierarchy in Hyperion Planning, which is a combination of members of the Entity, Version, Scenario and an additional dimension, handles promotion of single or multiple Entities for approval.

  • Reduction in Planning cycle time and effort
    Availability of a central system, capable enough to handle critical & requirements of Financial Planning process makes Hyperion Planning more efficient in terms of time and effort, when compared to Standalone Essbase based planning system.

February 13, 2012

Overcoming Innovation Challenges in Banks: Need for Strategic Thinking

Traditionally it has been seen that that banks lag their peers in other verticals when it comes to deploying innovation in business. The reason often mentioned is that the pressure for short-term gains overshadows the long term strategy of having innovation led business practices. However, in the context of looming economic crisis, banks need to revisit their way of working and put greater emphasis on innovations to stay ahead of competition and survive the economic challenges in the environment.

One source from where banks can get idea of innovation is its own employees. It has been found that source of ideas mostly come from employees rather than from the top management. Banks hence need to create an environment to incubate these innovative ideas from all strata of the employees, nurture them and put into meaningful and profitable business processes.

The other important source is the analysis of consumer behaviour. Shifting consumer behaviour in the wake of economic downslide worldwide and rapid growth of non-banking financial institutions also pose an opportunity to banks to incubate the innovative ideas. Though this is potentially not so dominant in banks, a focused approach in this area can provide the banks an opportunity to access to many innovative ideas, a careful analysis of which can really do wonders.

The third source is the market dynamics and the competition. Shifting market preference, technology enablement and enhanced speed of doing transactions can also be birth places of innovations.

The fourth source lies in promoting a network of external partners like vendors, customers and even IT service-providers and thrive for innovation through sharing experiences, pain points and challenges across the industry.

However, the emphasis here for the banks is to create an environment to promote innovation both in products and services space aggressively by aggregating all the sources of innovative ideas and then carefully analysing and then promoting them into next level of deployment and adoption. Some of the important levers for enabling this environment are executive ponsorship, availability of funds, suitable incentive structure for employees to innovate, providing a framework to cushion against failures, identification and investment in right set of people, and most importantly, promoting an eco-system that encourages innovation in an appropriate manner, with systematic investment in a long-term strategy.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter