Infosys-Oracle Blog

It has been just over a year since Facebook launched its Open Graph API.  It was touted as the next wave that would enable online retailers to target potential customers with personalized product promotions.  The Open Graph API is yet another step from Facebook to challenge the stranglehold that Google has on online search.

The Open Graph API made its debut just when Google's search results started losing its sheen.  Organized spam is already taking a toll on the quality of results one gets from Google.   Added to that is the issue of syndicated content farms that forced Google to even declare a war against it.  Given these struggles faced by Facebook's biggest and currently the dominant competitor, it is no surprise that the eCommerce community welcomed the Open Graph API with arms wide open.  It was considered to be the messiah of creating personalized content on the web, the tool that everyone was waiting for eagerly.

One year hence, the question naturally arises.  What has been the adoption of the Facebook Open Graph by online retailers?  Has it become ubiquitous across all retailers?  Though there is no official publication of such data from Facebook, there is enough anecdotal evidence to suggest that this is not happening.  The Blind Five Year Old claims that only 27% of the Top-100 retailers have adopted the Open Graph API.

The Facebook 'Like' button - the social widget that is almost synonymous with the Open Graph API - aids product marketing by providing quick feedback on how many people liked the product.  The first thing any campaign would be interested to know is whether the campaign was indeed successful.  The following are some of the questions that they will need answers to:

• How can one ensure that the 'likes' are converted into product 'buys'?
• What are the ways in which an online retailer can make use of this data?
• What analytical tools are needed to make the above happen?

Likes to Buys
If you are familiar with online retailing, you may be aware of a user's tendency to like many products that he/she happens to see on the internet.  Amazon was probably one of the pioneers to use this concept by creating their Wishlist feature.  While the shopping cart aided in immediate sales, the Wishlist was used by Amazon in two ways:

1. To remind the user during a later visit that they may be interested in buying a product that they were interested in before.  Very often, users tend to forget what they had liked earlier.  Unless reminded, this is as good as a missed sale opportunity.  
2. To recommend more products to the user based on what they bought and wished to buy during their previous visit.  If you had noticed, the more you browse and buy at Amazon, the better they become at recommending products that you may be interested in.

Online retailers can use these 'likes' to build similar recommendations.  Over a period of time, they will notice that they are getting better at predicting what a user is likely to like and actually likely to buy.  As Darren Vengroff says on his Mashable.com blog, a teenager may like a Porsche-911 but that may most probably not translate into a buy.  Therefore, organizations need to build a strong data models that can aid filter such noise and retain only data that may be most relevant to them.  A simplistic approach to this will be to associate various attributes with the product being launched that helps in targeting the customer segment.  Track only 'likes' of people who fall into this customer segment and focus on promoting the product or related products to only this segment.

Uses of the 'Likes' Data
The Facebook Open Graph API aids getting more data from a customer's 'like'.  When a customer likes a product, it is quite likely that the person's friends and people in his/her network are likely to have similar preferences or be influenced by the customer's preferences.  The Open Graph API can be used to post on the customer's Facebook Wall about his/her 'like'.  This is likely to be picked up in the news feeds of the customer's friends and in turn their networks.  There is a likelihood of this re-directing traffic towards the retailer's website. Additionally, when a customer visits the page where the product is promoted, the Open Graph API can be used to display information on how many of the customer's friends like the product being viewed.  It is also possible to list and highlight their comments that were added when they visited the page last.  These aid in building a common mindshare across a group of people who are already known to each other, thus raising the possibility of a buying decision.

Analytical Tools
The Facebook Insights is a platform that provides Facebook platform developers with metrics around their content.  It provides a dashboard that displays these metrics.  Alternatively, organizations can pull the metrics relevant to their business using the Open Graph API.  By persisting with this data, the eCommerce platform can be designed to use this data to provide more refined and personalized content.

The other advantage of using the Facebook Open Graph API is the fact that you are likely to trace users liking the product outside of your website.  The likes against links to the product posted on users' walls, the number of visits recorded from Facebook and other external websites are also indications of the product popularity.

Conclusion
Amazon, the pioneer in recommending related products, is tying up with Facebook now to leverage the 500+ million users on Facebook and their networks.  It is only a matter of time when more and more online retailers jump on to this bandwagon.  What is lacking today though is the availability of tools that aid in easy implementation of the Open Graph API as well as the limited analytics capability around the data that gets generated.  With the increasing popularity of social community based shopping and with increasing adoption from leading online retailers, it is only a matter of time when such tools start mushrooming everywhere.

Addendum
[Thanks to Saurangshu for providing me with the following tips]

1. The 'Likes' actually provide another opportunity to the retailers.  They can use this data to push a sale or any discount scheme that they may offer for one of the items that is on a customer's Like-list. This is similar to what Amazon does to customers who have added one or more products to their Wishlist.

2. There is an issue of a customer loggin into the retailer's website via the Facebook login screen.  This is currently a Javascript implementation and the customer continues to remain logged in opening up the possibility of Facebook monitoring their views on the retailer's website.  This may not be welcomed by most retailers.

3. If a customer visits the eCommerce sites of two competing retailers who implement the Open Graph API, Facebook may be privy to a customer's visits on both sites opening up the possibility of data being shared with the competitor.  This is definitely likely to be a huge contention before a retailer decides to implement this.  Facebook may need address this issue to increase adoption across retailers.

Posted by Shankar Viswanathan at 7:22 PM | Permalink | Comments ( 5 ) | TrackBacks ( 0 )

As the economic winds seem to be changing for the better, organizations are ready to venture out with grandiose plans. As the economy begins to heat back up, many organizations will consider the Warehouse Management Systems as a suitable opportunity to make investments. Many organizations had used the recession as a time to consolidate distribution operations. A combined operation, which may in some cases even involve different business segments or distribution process models, might have been manageable at recession-level volumes, but may become a bottleneck as the economy and unit volumes recover. Also when organizations try to align the business capabilities to technology capabilities based on the business model, investment in WMS may be an apt technology strategy.

The next important question that needs to be answered around the technology strategy is whether organizations should upgrade or replace their existing WMS. These questions are pertinent for any existing WMS due to three major reasons (FTS needs) as identified in many researches.

1. Functionality: The current WMS might not have the capabilities an organization needs to manage effectively in current times.
2. Technology: The WMS technology platform is antiquated, implying that it is hard to keep it running well, and it is difficult and expensive to maintain the system and/or to integrate it with other applications.
3. Support: With aging and archaic systems, sometimes a company really loses connections with original provider.

We are talking of huge investments when organizations embark on such journeys. These investments make economic sense only when the ROI crosses the hurdle rate. I recently read on how the ROI for a project relates to a probability curve (also mentioned in my last blog). It resembles Normal Gaussian Curve in ideal situations. The likelihood of it well exceeding the most likely ROI is usually small, so the curve usually starts to drop off pretty rapidly to the right of that number. The absolute reality is that there are a range of potential financial outcomes that are possible for a given initiative. It is important to understand the initiative's probability of success to achieve the ROI that is greater than the Hurdle Rate. Hence ROI as a number in isolation has not got a meaning unless it is associated with the chances of it being achieved. These kinds of analyses can help better understand the risk-reward trade-off of potential investment.

So what is the most logical sequence when it comes to strategizing? When considering the options of keep, replace or enhancing WMS, the most suitable sequence should be keep, enhance, and replace (KEP). As they say IT follows business, the sequence may be altered. Nevertheless, the economic viability of such investments and projects need to make sense. Even though what you have may not meet all of your needs, replacing it is the last resort option.  Enhancing the application is no longer constrained to integrating another piece of software or modifying the existing system you have.  Enhancement now includes the next generation of Enterprise Software, Enterprise Add-On etc. An appropriate technology strategy can set the organizations up to achieving their expansion missions with the markets looking buoyant.

Posted by Amit Sinha at 6:15 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Maintenance of linear assets (A kind of networks) is completely different from maintaining non linear assets like a fleet, machine. They through lot more challenges in modelling and executing the maintenance work compared to non linear assets. The ability to model and execute the maintenance these assets is what can tap the huge market potential in this segment.

Assets can be broadly divided into two categories namely Liner and Non linear. If we underrated non linear assets, it is easy to understand linear assets. Non linear assets are like Plant, equipment, Machine, fleet etc., they are confined to a size and specific location etc., Maintenance of them is relatively easy. Linear assets are not specific to single location. Linear assets can be like roads, runways, gas pipe lines, electrical transmissions, rail tracks, telecom lines etc., where they are not specific one single location. They more or less represent a network. Many linear asset networks cross over with other networks and can also be a place holder of many non linear assets. For e:g one railway track can connect to other railway track and also holds many non linear assets like traffic control systems, stations, power generating equipment and more importantly other parallel linear asset like power cables etc., Maintaining these assets requires much more capability than maintaining non linear assets.
There are many challenges that will surface in maintaining these assets. All these challenges need to be addresses adequately by any ERP to realize the benefits. Again the challenges will be different for different industries and this blog lists these challenges a generic manner.

1. Modelling of the linear assets: As the linear assets are not confined to a single location but widely spread across some geographies, modelling of these assets is the first most challenge for any ERP. This modelling can be either engineering or visual in nature. For e.g. a metro rail network is spread across a city. Typical asset hierarchy may not work here.

2. Assigning the non linear assets to the linear assets: Every linear asset can be a place holder for many non linear assets. For e.g.  a national highway contains traffic signals, light posts at definite locations also requires maintenance.

3. Parallel networks: There are some networks that work in parallel. A metro rail network requires a parallel power lines. Failure of any of them can result in stoppage of the services. Modelling of such networks is a challenge.

4. Intersecting networks: Networks that cross over. Typically can operate independently but the shutting down of one network can result in shutting down of other network. A metro rail network and a road network can operate independently but the shutting down of one network can result in shutting down of other network due to cross over at some places. This requires additional tag out processes.

5. Planned downime of the network: The linear assets or networks does not offer too much of a time for planned down time. They need to be scheduled typically on a weekend or public holidays by virtue of their connection to the public life. At times they need to be scheduled in summer only. This leaves additional challenge for the ERP systems.

6. Increased load on other networks: At times when one network is down, the traffic is to be diverted to the other network. This mean, some networks can't be planned for maintenance in parallel. Higher load on other networks means more usage that could result in breakdown as well.

7. Skilled personnel in performing the maintenance: Maintaining the linear assets needs a crew (group of technicians) from different departments to work at the same time. e.g. technicians from civil and electrical departments.

8. Special equipment in performing the maintenance: Maintaining these assets needs at times needs special crew. For e.g. a crane or excavator and their operators would be special equipment in executing the maintenance of these assets. Also arranging the required consumables to complete the maintenance work location requires initial assessment and planning.

9. Work orders planning and execution: Work order planning and execution requires much more co-ordinated process than non linear assets.  For e.g. arranging the crew from different departments, approvals from other departments even though the other department is not involved in the maintenance work. At times the maintenance of all networks is to be combined due to geographical constraints and same crew members. This also requires additional tag out processes.

10. Maintenance analytics: Apart from planning and executing the work, the ERP should generate the required analytics like down time trend, cost of maintaining the network, allocation of the costs to different networks etc., requires additional features.

Any ERP that can beat these challenges is sure to tap the huge market and we will see how Oracle EAM is offering various solutions to address these challenges in the subsequent blogs.

Posted by Murali Krishna Somisetty at 1:48 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

It is a pain! Does that sound familiar when you talk to a cost accountant about Enterprise applications/IT systems that support their daily work? Most of the Enterprise applications are built to address manufacturing specific cost accounting requirements, but they generally fail to address retail industry specific requirements. Here, we will discuss about some of the pain points or challenges from a cost accountant's perspective while implementing an ERP or IT system in retail industry.

1. Complexity in integrating the core IT application which maintains inventory and cost data with other warehouse management systems and retail store applications.

It is very common in the retail industry that the IT applications implemented in 3PL managed or company owned warehouses, manufacturing locations and retail stores are from different product vendors with different technical architectures. To integrate the operations across these entities, it will require building many customized solutions and interfaces between many disparate IT systems.

This inability to seamlessly integrate the accounting systems in the plant/warehouses/stores poses significant challenges in achieving global cost model, efficient overheads application and measuring profitability of stores across geographies etc. Cost accountants end up with the difficult task of maintaining accurate and consistent item costs across systems which involve lot of manual reconciliation effort and passing manual accounting entries.

2. Scalability of the custom built solutions and integrations is another serious concern for accounting consolidation when a company expands its operations with more manufacturing locations or warehouses or opening more stores in new markets. Indirectly the IT systems infrastructure with its inability scale up quickly impacts the growth of retail supply chain.

3. Most of the enterprise applications don't have standard built in processes to handle reverse logistics processes and related accounting in the retail industry. Cost accountants always face huge challenge in handling the accounting for short life cycle products like promotions, gift packs and seasonal items and subsequently retiring of these products.

4. It is another challenging task for the cost accountants to seamlessly track the new store development related processes and costs in a single system. It is very difficult to integrate the entire store development processes related to budgeting, procurement, construction, warehouse shipments till billing or capitalizing the asset in a single IT application. This result in lot of manual reconciliation effort and so the delay in reporting and analyzing the financial data.

5. Complex intercompany transactions and intransit accounting requirements are difficult to satisfy through standard product features which make cost accountants day to day life more difficult with lot of manual accounting effort. Some of the challenges in this area are Building flexible transfer pricing model as per accounting standards, FOB accounting aligning with both GAAP and supplier payment terms, Accounting material movements across companies/geographies with different IT systems or applications etc.

6. In a complex retail supply chain with huge number of stores/warehouses and high volume of daily transactions, managing daily inventory accuracy in the systems and there by achieving accurate accounting is a humongous task. With 24/7 warehouse operations and high volume of transactions, It is always a challenge for the cost accountants in getting the transaction failures and inventory discrepancies resolved on time, closing the periods on time, passing the right manual adjustments and generating the month end reports within defined SLAs. The enterprise applications can make a big difference in this area with its ability to provide timely, good quality data through standard reports and built in best practices for the period close.

7. The other areas where enterprise applications lack support for cost accountants in the retail industry are Flexibility in defining and accounting Retail BOMs, Reconciling COGS accounting between retail and warehouse applications, Flexible accounting based on Store groups/classification/types.

So it is always better to reach out to cost accountants early during the requirements gathering phase of any retail implementation project (to understand their pain!) so that you don't end up with big issues post go live. And then you can get to hear from cost accounting friends "Yes, That works!".

Posted by Vijaya Suresh Prabu at 6:42 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

The Oracle Exadata journey if i were to start from Version 1 to version 2, and now we have X2-8 version is quite interesting in terms of how it scales from an effecient platform for not only OLTP but a perfect recipe for what one can ask from a Data Warehousing platform. This blog is more about a sneak preview of some of the key features that one can expect out-of-the-box, and what really does an Exadata machine contains. Idea certainly is not to burden you with numbers, terms which one may not be able to grasp but to understand how Oracle is strategically aligning itself with the changing demands of the Information Age. Considering the topic and to do justice i am planning to split this into a series of blogs to focus on each of the key aspects. So why Oracle Exadata, and what is the big talk about handling big data. Am sure you might have read about the Data Warehousing appliance and how vendors claim the multi-fold performance gains in your data warehousing performance and effeciency. What seems quite unique about what Oracle has in offering is target end-to-end performance gains right from your OLTP Database, applications to your integration and OLAP storage, queries and all that in real-time with near no-impact on performance of your OLTP systems.

Oracle has reasons to claim Exadata being the only data machine that provides extreme performance for OLTP applications and DWH, makes it uniquely ideal for consolidation on grids or private clouds. Sun's Oracle Database Machine (as it is popularly know as) contains following key devices/softwares that make it complete, unique and integrated unit - its plug-n-power, connect to network and ready to run Database Platform:

• Database Server Nodes (Grid)
• Exadata Storage Servers (Cells)
• InfiniBand Switches (High Bandwidth)
• Ethernet Switch
• Pre-cabled
• Keyboard, Videos, Mouse Hardware
• Power Distribution units (PDU's)

Before we get into details of what each of those do and their roles, let's understand the potential benefits and power those components bring together to the table. These are components are pre-defined, pre-configured in a balanced fashion.

1. Consolidation of the mixed workload environments like ERP, CRM, Data Warehouse, Data Marts consolidate onto the database machine
2. Enhanced high performance and lower cost of ownership
3. Predictable response time in a shared environment - especially when its a multi-user, multi-environment and multi-node platform
4. Provides a complete, open and integrated platform for handling all the data management needs of any organization viz
• Bulk Data Processing as in case of Data Warehouse
• Random updates and frequent I/O needs as in case of OLTP
• Streaming files and multimedia needs
5. High availability and disaster recovery with protection from server, storage, network and site failures
6. Features like Online Indexing and table re-definition
7. Real-time remote standby platform open for queries/reporting over WAN (Active Data Guard)
8. Exadata plug-in to Oracle Enterprise Manager provides seamless integration and provides statistics, and performance monitoring of the Exadata Server environment with events & alerts to administrators
9. CLI (Command Line Interface) capabilities for administrators to manage multiple environments and servers
10. Sun's ILOM (Integrated Lights Out Manager) for providing remote administration and management of hardware e.g. power cycling the servers
    

A) Database Server Grid - provides tremendous gains in performance of transaction speed, queries and the amount of data that's processed per minute. The numbers claimed by Oracle being of the order of:
1. Millions of Transactions/minute
2. Millions of Queries/minute
3. Billions of Rows/minute

B) InfiniBand Network - from the Sun DataCenter InfiBand switch 36, provide a fully redundant non-blocking paths from Servers to the storage resulting in high bandwidth and low latency.
1. Provides 880GB/sec aggregate throughput
2. 2.88 TB/sec bi-directional bandwidth per switch

C) Exadata Storage Server Grid - The Exadata storage server software enables query processing in the storage, which otherwise was typically handled in the Oracle Database server nodes resulting in significant query performance gains. Exadata Storage server comes with interesting features like Smart Scans, Storage Indexes, Hybrid columnar compression and Flash cache (which removed spinning magnetic media bottleneck). We will explore some of those features in subsequent up coming blogs
1. 21 GB/sec disk bandwidth
2. 50GB/sec Flash bandwidth
3. 1 Million I/O per sec

Remember few of those points, and we will in next blog try to cover features more relevant to the Data Warehousing world and how those provide a great combination when looked in a wholistic prespective of OBIEE 11g.

To summarize we looked at key ingredients of Oracle Exadata, the benefits those ingredients when put together bring on table. The 3 key components Server Grid, InfiniBand Network switches and Exadata storage server grid together are making Oracle Exadata an all data management best of breed solution for OLTP and Data Warehousing platform.

Posted by Yogesh Bhatt at 12:23 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Pick any well-known beverage which you have tested in different parts of the world. They are produced in factories - miles and continents apart, but tastes same. Why? They maintain the formulation perfect. Can you imagine a situation that beverages available in East coast, West coast, Europe and Asia differ in taste?

Global market for Food and Beverage (F&B) Industry is more competitive and demanding. F&B Industry has to sustain changing consumer preferences and increased government regulations which impacts their manufacturing and business strategies. Major challenge in bringing the product to market after prototype development is its high lead time. Any product development function involves the Research & Development (R & D) team going through a lot of trial and error method which consumes considerable time and resources.

ERP can play a key role in formulation trial, quality checks and other R & D related activities to ensure the products reach demand locations at affordable price. The healthy management of R&D practices like simulation trials, parameter control, final product formulation, production formulas, quality, cost, etc. would bring spectacular re¬turns and huge savings to the Food and Beverage industries.

Oracle E-Business suite offers "Oracle Process Manufacturing (OPM)",  a pre-packaged application module,  which provides process industry specific business capabilities and allows innovations and full tracking of all the customer needs. Next few paragraphs highlight some of the key capabilities offered by OPM for Product Formulations.

Formulation using OPM

Formulation in OPM is achieved through judicial use of Least Cost Formulation (LCF) & Computer Aided Formulation (represented by Simulator & Optimizer). Let's see how it all fit together.

Least Cost Formulation (LCF) decides the best proportional use of ingredients and their quantities, resulting in desired product quality at least cost. This is achieved by the precise formulation control of technical parameters by OPM. The product formulation is arrived by specifying the final product technical parameter requirements together with either of the option - ingredient material requirements (or) ingredient compositional requirements. Based on it, the optimized ingredient requirements are arrived via the formulation engine at least cost.

The arrived formulation data values are populated to Simulator engine where the what-if scenario testing is carried out.  Formulators involved in R & D can re-adjust the ingredient quantities to get the desired output.  Subsequently, the simulated values are taken to Optimizer to further optimize the formulation using the criteria defined as key technical parameters.

Finally the optimized formulation is selected and a request is made to approve the formulation for laboratory use. The end result is batch or formula which could be created using this formulation specification under Quality Laboratory supervision. By this method, the optimized formula or a batch is directly created for product technical parameters properties at the least cost. The conventional - trial and error method of arriving the formulation is replaced with optimized formulation conditions with least lead time without compromising on product quality.

The desired Product or ingredient technical parameters with acceptable value range are specified at Organization level through Quality control tests and validated for Quality acceptance. The Laboratory batch which is produced, either directly through Formulation specification (or) with Standard formula with recipe combination, is executed and their quality test results are submitted for review. If the test batch produces the expected results in terms of yield, cost and safety, then it can be sent for approval for use in production. The test results of the Laboratory batch could be validated with respect to different batches and also multiple lots in the same batch.

OPM supports effective Formula management through tight version control and elaborate security features. Team of formulators and process engineers can collaborate to develop and maintain new and existing products using the Formulator Workbench in OPM.

To Summarize, Oracle OPM Formulation helps the food and beverage industry in meeting of the challenges in the area of Product formulation, Quality assurance, food and safety.  The repetitive execution of expensive laboratory test batches due to inherent product variability is controlled through Optimized formulations. It helps in reducing R&D expenses and achieving robustness in product engineering for a market win.

Posted by Ashish Namdeo at 12:20 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Continuing on the ETO Series, I will discuss about the concept of Seiban, How it works and the key business requirements in Build To Order (BTO) Industry that can be handled in Oracle EBS Seiban solution. Another prominent ERP product that addresses Seiban requirements in the Industry is Glovia from Fujitsu.

 What is Seiban?
The Japanese methodology of separation of inventories using an identifying number where the number is attached to on-hand Inventory, purchase orders and manufacturing jobs on supply side to identify them as belonging to a particular customer order, contract or project. This identifying number is called Seiban derived from Sei meaning "Manufacturing" (or Production) and Ban meaning "Number."

Why Seiban?
In most of the manufacturing scenarios, materials and resources are allocated to production orders based on their urgency of the customer orders which does not work well for Build To Order manufacturers. In Build-to-order manufacturing, the key requirement is to track and segregate materials and activities for specific customer orders which enable visibility and trackability of the customer order throughout the manufacturing and supply chain cycle.

How Seiban works?
A unique identification number, the Seiban number is allotted to a particular customer order and subsequent supply orders, purchased materials, activities and services performed for that customer order inherit the Seiban number to enable trackability.

The key features that Oracle offers for implementing a Seiban manufacturing system are,

1.Ability to link and track Demand and supply for Customer Order/Project/Contract (Seiban)
2.Tracking Seiban Execution in shop floor and supply chain.
3.Providing Identification and allocation of Inventory for Seiban;
4.Cost tracking for specific Seiban
5.Ability to view, track, report Seiban specific activities and detailed drill-downs
6.Ability to handle material transfers across Seibans including borrow/pay back and mass transfers
7.Ability to support Lean practices and ATO/PTO business scenarios
8.Visibility to Seiban profitability
9.Integration with Quality systems - To track back defects in a customer order (Seiban).

Here are the few limitations in Oracle EBS in supporting a Seiban system,
1. No single view for all Seiban costs and revenues without Oracle projects installation
2. Ability to use WBS/ Tasks not possible.
3. Oracle does not support reservations at Seiban level.

Posted by Vijaya Suresh Prabu at 9:38 PM | Permalink | Comments ( 3 ) | TrackBacks ( 0 )

Guest post by
Dilesh Deepak Dattani, Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

A lot of Indian companies in Utility Space have either already started or in the process of starting implementation of IT Systems to which would help in increasing their operational efficiency and reducing costs. In this post I would like to highlight some of the typical challenges which we come across in such implementation projects in India.

1. One of the very important aspects in implementing a Meter Data Management (MDM) System is the parameters which the meters can record and provide to the system for downstream activities.  A very common challenge in the utility space is the lack of a proper standard which governs the number of parameters that a meter is supposed to give.  As a result of this, today in India we have meters of various makes which provide wide range of parameters. There is a lack of consistency in the parameters provided.  That is the parameters provided are different across the meter manufacturers. This makes it difficult to design a system which could use these for various purposes like Billing, Reporting, and Energy Accounting etc. Moreover most of the meters in place, use different protocols and it becomes difficult for the head end system to be configured for receiving inputs from meters of different makes.
2. Another challenge of implementing Meter Data Management Systems in a country like India is the Regulatory Rules which exists here for various functions like Estimation, Billing. Usually such rules would have been formed based on the older methods of data collection and billing. By Implementing Meter Data Management Systems the granularity of data available changes drastically and hence the regulatory rules too need to be in accordance with that.  In absence of proper regulation rules there are risks pertaining to litigation by the end customer. 
3. Communication Systems and the coverage of the same becomes extremely crucial for implementation of such projects because it is the communication system which determines the speed and accuracy with which the data from meters reach the MDM. It is based on this data that all the subsequent downstream activities like reporting, billing , energy audit etc takes place. In a place like India this could be a big challenge as the consistency in connectivity is not guaranteed especially in remote areas.
4. Yet another crucial aspect in any MDM implementation is getting the attributes of meters installed in the field. Invariably it so happens that a Survey needs to happen to provide the details for the meter. Besides this, information pertaining to the hierarchy of assets like feeders, transformers etc which are needed for doing an energy audit are also obtained through these surveys. There are multiple challenges in performing an accurate and fast survey. One of the issues is that the details/attributes of the meter which are usually printed on it are either wiped out completely or illegible. Moreover certain attributes pertaining to the meter has to be configured when the meter is installed. Hence Survey cannot provide these attributes and the only way is to extract the data by having a head end meter read system.  An example would be Meter Serial Number which can be used as a unique identifier for the meter might not be directly available externally.

Posted by Guest Blogger at 2:22 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Pierre Simon de Laplace once said -"The most important questions of life are, for the most part, really only problems of probability." With technology moving at a rapid stride and organizations expanding their IT budgets many new projects are getting kick started. In WMS space there are popular initiatives like Cloud WMS, On Demand WMS, Harmonized or Consolidated WMS to name a few that organizations are planning to invest in. So as the economic winds seem to be changing for the better, organizations are ready to venture out with grandiose plans.

Potential projects and investments go hand in hand and are closely tied to Return on Investment. A popular term in financial parlance is the Hurdle Rate. Let us try to understand it a little better before we go into further discussion. Hurdle Rate is defined as the required rate of return in a discounted cash flow analysis, above which an investment makes sense and below which it does not. It is also called required rate of return.

Therefore it is imperative that project returns are substantially higher for them to be economically viable. The next big question is what is ROI? Well, traditionally speaking ROI is calculated by adding costs of the project and line them up against the financial benefits over some period of time. This can be calculated by many popular methods like Simple payback period calculation, internal rate of return, discounted cash flow, etc. So in effect the ROI needs to be greater than the Hurdle Rate to be economically viable.

I recently read on how the ROI for a project relates to a probability curve. It resembles Normal Gaussian Curve in ideal situations. The likelihood of it well exceeding the most likely ROI is usually small, so the curve usually starts to drop off pretty rapidly to the right of that number. The absolute reality is that there are a range of potential financial outcomes that are possible for a given initiative. It is important to understand the initiative's probability of success to achieve the ROI that is greater than the Hurdle Rate. Hence ROI as a number in isolation has not got a meaning unless it is associated with the chances of it being achieved. These kinds of analyses can help better understand the risk-reward trade-off of potential investment.

This seems to a plausible argument when it comes to customizations of standard WMS packages. For instance, high levels of supply chain software customization unquestionably add risk thereby increasing the probability of failure in case of certain WMS packages like Manhattan. This puts a question on achieving the ROI, organizations are aspiring for. It also opens up windows for evaluating other WMS packages that can provide customization with ease without posing much risk like Oracle WMS for example. So, even if the theoretic return is higher with the customizations, the trade-off may look much less favorable when the risk is considered. Same thought process could also be extended when an organization would evaluate a site out of the many distribution centers it has, for a pilot roll out of its consolidated WMS system.  

In effect organizations assess the economic viability of any WMS project by associating it with the probability of success, the gestation period involved along with other factors. But as they say, if the probability of success in not ONE, then it is as good as a ZERO.

Posted by Amit Sinha at 5:54 AM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Sourish Chatterjee, Lead Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

In my last blog, Business Intelligence in Oracle's Fusion Applications- Always Available, I had discussed that Fusion application Business Intelligence comprises of the following:

1. Oracle Transactional BI (OTBI) is real time self service reporting directly off Fusion Apps data. It has pre-packaged content covering major Fusion applications.
2. Oracle BI Applications (OBIA) is a prepackaged data warehouse enabling historical analysis and cross domain insight.
3. Specialized Domain specific Analytics include financial statements, sales territory planning and Project Performance built on Essbase technology. White space analysis built on Real Time decisions and Oracle Data Mining Technologies.
4. BI Publisher reports are also available; these are out of box content within Fusion applications to cater to pixel perfect and highly formatted report requirements.

Let's now see how all the BI Content can be accessed within fusion applications.

1. First way to access it  is from the Fusion transactional Screens (Embedded Analytics)
   BI reports are embedded in many places within fusion transactional screens. While performing transactions fusion applications users can view contextual analytics embedded within the transactional screens. While receiving material users can see earlier rejections trends, while performing HR transactions users can view workforce trends and compare performance. These analytics support bi-directional event integration. This means when the user selects a customer or Supplier for transaction, the embedded analytics automatically refreshes with the filtered context.
   Fusion Applications also contain embedded BI Dashboards. These are entire BI dashboards which are available as tabs on fusion home page. Many such role based dashboards supporting common analysis are embedded within fusion applications.
2. Another way to access BI content is the reporting pane
   The reporting pane which is available on the right hand side bottom of the fusion UI shell displays a list of contextually relevant reports. If a user is performing a PO transaction, spend analysis related reports would be displayed in the reporting pane. One click will launch the report in a new window. The reporting pane is also customer configurable, so users can save reports under "My Favorites" and "My Reports".
3. Finally, Navigator/ Main Menu can be used to access BI
   The fusion applications main Menu has a submenu called "Analysis and Reporting". Clicking on this menu item will launch the BI Home page. The BI Home page contains the BI content catalog. Fusion Apps will use OBIEE web catalog to store all shipped reporting and analytics content.
   From the BI home page users can browse and view the entire BI content. The BI catalog folder structure will match the Fusion Apps main menu structure. Folder structure would be content driven not technology driven which would enable ease of navigation for fusion Apps users.

Following content will be available under the BI catalog structure:

• BI Publisher Reports (regardless of data source)
• OTBI reports & dashboards
• OBIA dashboards & scorecards
• Financial Reporting

Also, users can do some additional actions from the BI Home page like: Access personal and shared reports, View/ edit BI publisher report schedules, Launch BI tools for advanced actions and create new reports with report wizard.

New reports created can be saved in BI catalog and added as embedded content within Fusion applications screens or links added to reporting pane. This enables users to extend the prebuilt embedded analytics within Fusion Applications.

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

Guest post by
Harish Ajjarapu, Technology Architect, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Oracle Business Intelligence Enterprise Edition (OBIEE) is a comprehensive solution platform for enterprise business intelligence, including a scalable and efficient query and analysis server, an ad-hoc query and analysis tool, interactive dashboards, proactive intelligence and alerts, real-time predictive intelligence, and an enterprise reporting engine. Recent release of OBIEE 11g has moved one step ahead in terms of completeness, scalability and integrated the security with Middleware products like Web logic being added to the mix.  Earlier versions of OBIEE (up till 10.1.3.x) while having Object and Data level security, it was often prone to tweaks and workarounds to achieve the Role Based Security using various authorization mechanisms.

In this blog, I hope to discuss the level of scalability Oracle has provided with respect to Object and Data Level Security in OBIEE and highlight the out-of-box Role Based security features of the product.

Key features to notice in the 11g security framework are:

1. There is a shift in Architectural Approach so as to pre configure with initial default values in  the default security model by adding
   o Identity Store: Contains the definition of users, Groups and group hierarchies required to control Authentication.
   o Policy Store: Contains the definition of application roles, the permissions granted to the roles, and the members (users, groups, and applications roles)    of the roles.
   o Credential Store: Stores security-related credentials, such as user name and password combinations, for accessing an external system, such as a database or LDAP server.
2. Alignment with OPSS
   OPSS is an Oracle Platform Security Services with
   • Standards based, portable, integrated, enterprise grade security framework for Java applications
   • Underlying security platform that provides security to Oracle Fusion Middleware
   • Including WLS, SOA, WebCenter, ADF, Entitlement Server
   • Abstraction layer in the form of standards-based programming interfaces (APIs) that insulate applications from security infrastructure
3. Centralized Maintenance of the Security Using EM and Admin Console
   Enterprise Manager is used as the centralized maintenance of the security like any other Product of Oracle. Oracle 11g FMW Enterprise Manager is used to maintain the Application Roles and Application Policies, where as the authentication Providers (like LDAP, DB Authenticators and so on). 

The implementation level process or steps in the OPSS includes

• Authentication
• Identity assertion
• Authorization, based on fine-grained JAAS permissions
• The specification and management of application-specific policies
• Secure storage and access of system credentials through the Credential Store Framework
• Auditing
• Role administration and role mappings
• The User and Role API
• Security configuration and management
• SAML and XACML
• Oracle Security Developer Tools, including cryptography tools

The key components and the architectural representation of the OPSS discussed above are shown as:

OPSS Security Architecture

In brief, Whats' changed in 11g Security?

• Identity Store is embedded LDAP server (WLS)
• Users available everywhere
• Application Roles available everywhere
• User Profile derived from LDAP server
• Users/Groups no longer defined in RPD
• Administrator and Administrators not hard-coded
• RPD protected by RPD Password
• Administrator user not used for Inter-Process
• Communication (component to component)

Whats' not changed in 11g? (Basically anything that works in 10g)

• Init Blocks
• External and Custom Authenticators
• Database Authentication
• SA System Subject Area
• RPD access control
• Web Catalog access control

More details on integration of the security framework with Fusion Applications and setting up the Policies and Roles will be covered in the next series of this blog.

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

Guest post by
Umesh Tanna, Senior Technology Architect, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

Consolidation is one of the many key reasons for deploying and using Exadata. Oracle Exadata is an appliance - hardware and software bundled and engineered to provide maximum performance. It is a database machine that is purpose built and integrated. True, that there are high end systems that are best suited to be replaced by Exadata platform considering the growth and performance need of those system. However, by design, Exadata offers high end configuration and specification which not all types of Oracle database application that today runs in IT department need.  Hence, solid business case can be built for those systems if, some type of consolidation solution is considered which can simplify, increase availability and performance and ultimately reduce total cost of ownership.

As soon as someone speaks the word consolidation, one asks - How can we run our OLTP and data mart application on single server/database? Can we have package application and custom application running on same server/database?  While we are ok to tolerate certain hours of downtime for our data warehouse database, we need 24x7 operations of our OLTP. Do you have solution for this? How would we handle the situation that runaway queries in our data warehouse application do not make OLTP applications starve for resource?

Now before we see how Exadata answers such questions, let us see what the various ways are in which we can consolidate into Exadata platform.

One simple consolidation scenario is bringing multiple databases (may be running on multiple servers) as it is into exadata. What we achieve in this is server and/or OS consolidation.  Advantage of this approach is database still enjoys database level isolation and thereby flexibility in configuration and operation. However on the flip side, this may still result in lots of overhead because of multiple databases.

Next level of consolidation is database consolidation in which multiple databases (may be running on multiple servers) is consolidated in one database running in exadata. While this requires very careful planning but advantage of this approach is better resource utilization, simplicity and very less overhead.

Oracle exadata v2 offers various features and functionalities that enable superior and effective consolidation and provides solution to many of the questions. Of course consolidation exercise need to consider multiple aspects of their IT environment, policies and procedures and each may have their own unique challenges; however, understanding following feature helps us to explore the suitability of exadata for consolidation.

Database Resource Manager (DBRM)
IO Resource Manager (IORM)
Mix workload
Oracle Service
Server Pool
RAC One
Instance Caging

In the next part of this blog we will understand how this feature helps in database consolidation.

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

Supply chain across industries today is increasingly becoming global, complex and dynamic as enterprises are striving hard to navigate through the economic whitewaters. While Value-Added-Resellers, Original Equipment Manufacturers, Retailers, Pharmaceutical Companies (I'll refer all of them as OEM in the rest of the article) are focusing more and more on core competencies such as Brand Building, Product Design, R&D, manufacturing operations are outsourced for cost effectiveness, quicker time to market, improved capacity utilization, access to global network and superior technology or simply build where you sell. Based on iSuppli market research, the contract electronics industry, consisting of the electronics manufacturing services (EMS) and original design manufacturing (ODM) segments, will finish 2011 with revenue of $376.7 billion. The global contract manufacturing market for pharmaceutical industry is expected to grow at a CAGR of around 11% during 2011-2013. Rapidly emerging contract manufacturing destinations are Eastern Europe, Latin America besides Asia Pacific.

Like anything else the key ingredient for outsourcing business relations is information sharing and collaboration - from start-up, through forging/building and sustaining the relation.  Typically master data (part number and its life cycle status, suppliers, Country of Origin), supply chain visibility, traceability and modeling contract manufacturers' capacity have always been the major challenges. Although Enterprise Software Applications address almost all of these requirements, except for a few large contract manufactures such as Foxconn, Flextronics in EMS Industry, for the most part Contract Manufacturers (CM) are not fully integrated with OEM's supply chain. OEM(s) rely on the tribal knowledge, offline processes that are broken, and deal with the multiple sources of record. The problem is compounded when multiple contract manufactures are involved in different stages of manufacturing of the same end product. It is a nightmare for a supply chain planner to piece together the shreds of information and come out with a feasible supply chain plan, let alone lot/serial traceability to address product recalls.
Typically these relations can be classified into two models - Inventory Ownership Model and Drop Ship Model and can be mapped in OEMs' IT system accordingly. In Inventory Ownership Model, inventory is owned by the OEM; OEM provides/ships the ingredient/raw materials to CM, CM adds value, OEM pays service charges for the value added by the CM and goods come back to the OEM's production facility/distribution network. Incase of Drop Shipment Model the CM ships goods directly to the end customer. For the former model enterprises can create a virtual production organization for each of CM(s) which would mirror manufacturing, inbound and outbound transactions physically occurring at CM.  Interfaces can be built to seamlessly integrate master data, production schedules, and transactions. OEMs may also choose to give access their IT system to CMs to view and perform transactions (must be included in contract agreements to avoid down the road problems).With the Organization Security feature only pertaining and relevant information can be shared with the CMs. Further CM's resource availability and capacity can be easily modeled in the virtual production organization.. Although in the latter model, Inventory is not owned by OEM, CM's capability to build information is important to supply chain planner for medium to long range planning. Also Buyers can be alerted for expected volume changes and Purchase Agreements can be negotiated in time. Here too a virtual planning organization can be defined to hold CM's capacity information. A global supply chain plan would include these virtual organizations along with OEM's production organization and distribution centers to provide supply chain planners with valuable insight about the inventory position, material and capacity constraints, longer lead times and critical path.  Also, transparency and communication flow significantly improves across business functions such as product life cycle management, transportation management, freight management, inventory reconciliation etc. As the Lot/Serial numbers and their attributes can be captured in transactions in virtual orgs, lot genealogy and traceability information is readily available in the event of product recalls/customer complaints.

It is virtually impossible to ignore benefits of outsourcing of manufacturing operations; such relations can be bolstered by leveraging IT Applications/ solutions that provide master data management, supply chain visibility, lot/serial genealogy, help identify the bottlenecks and build an 'agile' supply chain to respond quickly to demand fluctuations.

Posted by Kallol Kumar Kar at 9:47 PM | Permalink | Comments ( 0 ) | TrackBacks ( 0 )

Guest post by
Amit Tuteja, Senior Consultant, Oracle Practice, Enterprise Solutions, Infosys Technologies Ltd.

 

I was lucky to be part of one of the complex Oracle implementations done by Infosys Oracle Practice in Retail industry. During my work with this large retailer I got the opportunity to work on design phase and later got involved in testing phase. Most of us understand and realize the importance of Testing in any implementation but in this blog I would like to emphasize how a well planned Testing phase increased Management/ Stakeholders confidence and paved the way for a successful Implementation.

Here are some of the key things in testing that helped in making this implementation a successful one:

• Define the Roles, Independent Testing Team: In many projects Design and development team spearheads the testing but in this case an independent Testing team with mix of Technical, functional experience  was put together to Test the product. Roles like Test Leads (for direction with regards to test scope definition and test deliverable review); Test coordinator (coordination, status reporting and planning) and Test Analysts (Test execution) were defined. An Independent group for testing ensured that the RICE passed through different set of eyes which help catch some things that might have got missed otherwise.
• No success can be claimed unless it's measurable! Reporting: Timelines and scope of work were defined clearly and progress was maintained through Test Calendars. Weekly meetings were scheduled with Stakeholders/Management to apprise them of the Testing status. These meetings ensured issues/risks were brought out on regular basis and any concerns were resolved quickly. This regular reporting/touch base exercise with management helped Test team set the priorities in case of conflicts and helped the team stay on Track.
• Devil is in the details, the System Test phase: This phase was the longest in duration and laid the foundation for success. The testing team read the designs and wrote Test cases at a detailed level which captured the functionality of RICE to be tested in detail. Focus was not only on testing but also on documenting what was being tested. These test cases were reviewed and approved by Test leads which instilled confidence in Leadership that Testing was being carried out thoroughly.
• Look at the Flow, Integration cycle1 testing: The Test leads (experts of various process flows) along with Test coordinators put together most critical business processes which had to be tested thoroughly. These end to end business processes were then detailed out to form Test Sets consisting of multiple tests. Testing with data from Legacy applications kick started in this phase.
• Connect externally, the 3PL testing: The testing of custom Interfaces with 3PLs (Third Party Logistics Providers) was treated as a separate activity as it involved co-ordination with different parties outside of the organization in different time zones. Thorough testing with 3PLs ensured that there was a seamless flow of data between the Organization and the third party vendors.
• Involve the experts, Integration cycle2: This is when things started coming together. The end to end flows defined in IT1 were executed with data flowing between core system, legacy systems and the 3PLs. Super users were roped in this phase. Super users were the SME's who were responsible for various core areas in system/business. They looked at the End to end scenarios prepared by Test team and gave valuable inputs thus ensuring the accuracy of the flows and processes. Engaging super users early on gave enough time to make changes or cover gaps (if any). 
• Teach the user, Training: Training was being run in parallel and the training Team was able to utilize Test sets created by the Testing Team for demonstration of critical business flows. Training team also took help from testing team for demonstration in the applications. This helped the program to gain the confidence of end user.
• Test the Performance: Retail business is all about volume and it is very important to do the performance testing for critical Customer facing processes. A subset of testing team was engaged to do a Performance testing simulating the load which system would carry on one of busiest days.
• Rehearse it! Integration cycle3: There is no better recipe for success than continued practice. During this phase all the critical business processes were tested in a different environment to simulate Production like environment. All the 3PLs and Legacy systems participated in this cycle and the results were captured in Quality center. The Super users reviewed and signed-off on IT3 results.
• The Final Blow, CERT: By now the Team was confident about system's performance and behavior. Certification testing was run for all the Business critical flows and the ones' which had issues in previous cycles once again in an environment where Dress Rehearsal of Cutover activities was performed. This increased confidence of the management, stakeholders and Super users thus paving the way for a successful implementation.

Along with testing other important areas like design, development and deployment were also managed very well which lead to a successful implementation.

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

We have all heard-What happens in Vegas stays in Vegas. Similarly What happens in a Warehouse stays in the Warehouse. This is the Inside Story of a Warehouse. Okay, melodrama set aside, the inside story of a warehouse comprises of the inbound and outbound processes.

In-bound processes are can be simplistically classified into Pre-Receiving, Receiving and Putaway as we have discussed on earlier occasions as well. At a high level following processes form the inbound logistics of a warehouse:

1. Appointment Scheduling
2. Pre-Receiving
3. Receiving
4. Quality Assurance and Vendor Audits
5. Putaway

Pre-Receiving, which begins with the ASN, typically accounts for about 10% of operating costs- thereby commanding the attention it deserves.

An Advanced Ship Notice (ASN) is a form of electronic communication (EDI 856 transaction) sent from a supplier to a warehouse that details what goods are coming in what shipments before they arrive at a distribution center or warehouse. ASNs will often include PO numbers, SKU numbers, lot numbers, quantity, pallet or container number, carton number. While the specifics of a ASNs' contents can vary by industry or even individual supplier-customer relationship, in the consumer goods to retail sector ASNs generally involve carton-level content detail tied to GS1-128 (formally UCC-128) serialized bar code labels on each carton.

The benefits of quality ASN data are numerous, including increases of 20-40% in receiving productivity (as confirmed in many a research), better labor planning and allocation, the ability to pre-allocate merchandise to stores, improved supply chain visibility, and other enhancements to supply chain performance. In a recent WMS implementation I was involved in, receiving operations observed a 33% increase in productivity after Mobile RF devises were introduced to collect the receiving information. Prior to the implementation, these processes were handled manually. Add to this, quality ASN information, and imagine the benefits that it could translate to.

In a traditional ERP implementation Expected Receipt Instructions can be sent to the WMS wherein ASN is one of the receipt types. Against this expected instruction warehouse needs to perform the receiving action and reciprocate with a Receipt Confirmation instruction.  So systemically the Data Flow could be understood in terms in the involvement of the following:

• Supplier Sends the Shipment Information to ERP via TMS (Transportation Management System)
• ERP processes the information and generates an Excepted Receipt of Type ASN to the WMS
• WMS sends back the Receipt Confirmation to the ERP

In case an organization chooses to deploy Oracle EBS, Oracle WMS would be implemented including MSCA and Oracle Inventory. This would reduce the overhead of ER/RC interfaces, but still be able to process the ASN information from the supplier.

ASN accuracy has to be measured in terms of not just that what is on the ASN, but also that the EDI transmission meets the retailer's technical requirements and can be processed automatically. In order to derive the fruition of ASN processing Supplier Labeling Compliance is a pre-requisite.  Once the compliance is established, it ensures a seamless information flow between the systems.

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