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

« January 2009 | Main | April 2009 »

March 27, 2009

To ETL or to EL-T: that is the question

Between ETL and EL-T apart from the superficial difference in the positions of the letters L and T there lies a deeper difference in the very philosophy of how data integration is performed in each of these patterns. Before we get into the technical differences and relative benefits let me first lay down the two philosophies of data integration
While ETL stands for “Extraction-Transformation-Load” the core or “most” of the Transformations are performed on the ETL/Data Integrator (DI) engine with extraction and load routines being run on the source and target database engines. On the other hand an EL-T philosophy of data integration completely utilizes the target database to perform the Transformations. It applies what is popularly known as “pushdown” to the database engine.
As we all know “Transformation” is where most of the resources and time are expended in an ETL work and hence a lot depends on where transformation is done, how effectively it is being done and whether the right optimizations are being applied while carrying out the transformation operation. Working wisdom dictates that it makes more sense to run the complex and resource consuming transformations on the data base engine as compared to running them on the ETL engine or in other words “push down” operations make sense when the operations are complex or the data volumes are large. I would believe that  most ETL developers or designers would have had some experience in their life time where they would been required /forced to create a PL/SQL, T-SQL package or stored procedure and call it from the ETL workflow to work around some complex or volume intensive operations. So theoretically one can use an ETL tool and pad it with native data base routines to get around the volume or complexity issue. However this may lead to a very disruptive architecture and a complex data model in trying to make the data transformed by the ETL engine made available to the packages and routines to carry out further transformations. This shortcoming could be replaced by adopting a EL-T philosophy to handle the complete data integration issue and provide all the transformation operations on the native database.
So how are the market leaders in Data Integration space oriented vis-à-vis these two different integration patterns?
Most of the best of breed tools like Informatica, IBM DataSatge, BO-Data Integrator, Ab-Initio offer the ETL philosophy of data integration. Although they claim to be pure play ETL players but they always used some to large amount of “pushdown” optimization techniques. For example BO-DI optimizes its aggregation, joins and sort transformations by actually pushing them down to the database engine and making them work faster.
On the other end of the spectrum is Oracle with its Oracle Warehouse Builder (OWB) which essentially transformed all the mappings created into PL/SQL packages and executed them on the Oracle RDBMS which I believe is very much an EL-T philosophy with all its transformation being done on the DBMS. As an icing on the cake Oracle acquired (which I believe may have been deliberate) Sunopsis in 2006 which was  then probably the only other best of breed EL-T tool available in the market and now with these two being integrated in the near future I would expect to see a real enriched EL-T tool in the making. Also an interesting pattern that we can observe is with Informatica. Informatica Power Centre from Version 8.0 onwards has come up with an option of using either ETL or EL-T or even a hybrid option. I would want to believe that this is testimony to the fact that erstwhile pure play ETL players are seeing merit in adopting an EL-T philosophy and offering the same to its end users.

March 22, 2009

Why Lean may need ERP?

The traditional thinking is that Lean and ERP are contrary to one another. Lean signifies a pull system and simplicity whereas ERP signifies a push-based complex environment that relies on innumerable transactions at every step to run smoothly. Lean is reality-oriented while ERP is data-in-the-system-oriented. One can argue forever on these lines…

If one scratches the surface, however, it does not seem so contrarian after all.

Consider some real-life examples below from my consulting experience where an ERP system assisted the lean philosophy of an enterprise.

 

Kanbans: The simplest form of Kanban relies on containers with a card number. An empty container can imply either movement of material, in a lot size equal to the Kanban size, from another location in the plant such as the warehouse (Intra-plant Kanban), production of an assembly (Production Kanban), purchase of material from a supplier (Purchase Kanban) or purchase of material from another plant of your company (Inter-plant Kanban).  While the movement of an empty container as a physical indicator may be feasible over small distances, it is not necessarily possible over long distances particularly when the container is not part of a reverse logistics system.  In such cases, an ERP system’s Kanban functionality can help achieve some of the same simplicity of operations using an electronic signal rather than a physical one. A board of bar-coded Kanban cards and a handheld device to scan an empty card can be used to trigger either a move order, a work order, a PO or an internal PO. This helps alleviate distances and cards lost in transit.
Another situation where an ERP can assist in a Kanban environment is to identify uneven demands. To function successfully, a Kanban system assumes an even level of demand. Placing a Kanban item on MRP to monitor future demand can be a good idea to identify bumps in demand. The replenishment still happens on visual cues and not from MRP; a planner simply sees the MRP horizontal plan to make sure there are no surprises ahead.

Most ERP systems do Kanban calculations for Kard size or the number of cards based on historical or forecasted usage.

Backflushing: Most ERP systems support backflushing of components during manufacture. By having components on the shopfloor rather than stacked high in warehouses, you can ensure a lean operation as it reduces the overheads associated with kitting from the warehouse for an individual job and carrying each kit to the shopfloor. ERP systems assist in this Lean initiative by directly backflushing material on completion. A Kanban system can then be used for the movement of inventory between the warehouse and shopfloor either based on physical movement of cards/containers or electronic signals

Cellular/flow manufacturing:  ERP packages assist cellular manufacturing (self contained units with material in close proximity of the operator) and flow manufacturing by providing work order-less completions wherein a single unit of an assembly can be completed and the corresponding quantities of raw material backflushed at the press of a button. This is extensively used in organizations to reduce batch sizes to the point that a single unit is completed each time. This obviously requires flatter bills of materials or use of phantom levels.

Electronic communication with supply chain partners: Using supplier and customer portals can eliminate wastes such as paper-based communication and most ERPs support such portals. Suppliers can receive POs, send acknowledgements and invoices electronically. Similarly, customers can place their orders electronically and check the status online.

Workflow: Workflow-based processing, a standard feature of most ERP systems, is another step in the direction of Lean as it promotes a sequential flow of process in manufacturing and order management.
The above cited examples do signal reconciliation between the ERP and Lean way of thinking. Finally, the two don’t seem mutually exclusive.

March 19, 2009

Give your ERP a Lean Boost

ERP drives enterprise-wide planning and scheduling of resources to satisfy your organization’s needs of manufacturing, procuring and shipping of goods. The planning and scheduling outputs that an ERP provides, is based on the various input parameters fed to it such as lead times, safety stocks, order modifiers, product structures, supply and demand, stocking levels, etc. Based on these input parameters, an ERP plans for the short-term and long-term resource requirements for your organization. However, in order to derive the maximum benefits out of your ERP deployment, you need to validate that your organization is efficiently managing these input levers to your ERP. It is here that Lean manufacturing and Lean supply strategies can help you in reducing the fat that often accumulate in these input parameters. This is where Lean operating principles that focus on eliminating waste from the processes can help an organization streamline its operational levers to derive the best benefits out of an ERP implementation.

There are several ways in which ERP can complement a Lean initiative. For example, a Lean organization would focus on reducing demand variability not by raising inventory stocking levels or padding up lead times rather by increasing the flexibility in manufacturing to reduce cycle times. A Lean organization rather than promoting fixed lot multipliers to reduce ordering inefficiencies would focus on collaborating with suppliers to do intelligent and just-in-time procurement. ERP enables sharing of data with suppliers, whereby an organization can look at the available capacity of its suppliers and in turn the suppliers can look at stocking levels of their customers to decide on when to replenish. An ERP can go a long way in developing such collaboration.

When it comes to Lean material replenishments, most ERP packages have built-in support for Kanban planning and execution. Kanban is a self-regulating replenishment cycle which can operate extremely well through visual signals. However, visual signals may not be the most efficient across large shop areas due to difficulty in viewing these signals. When supported by an ERP, the Kanban system can become even more powerful and overcome the space limitations that visual Kanban signals might face. Similarly, ERP packages have built-in support for other Lean methods such as in-process quality checking, pull-based replenishment, backflushing, vendor managed inventory, etc. Oracle Apps provides a Flow Manufacturing module that provides customers with support for flow schedules, mixed model maps, takt time calculation, line balancing and flow schedule managing and execution. In fact, the unified data model that ERP packages uses, can be used to develop some custom tools that can utilize the data stored in ERP and yet meet some Lean initiative needs that the ERP package of choice might not offer. We did such a customization to help an industrial manufacturer classify incoming order lines into value streams – a Lean concept.

While ERP can support some Lean initiatives, as is well known, Lean planning and execution is a cultural and operational change that an organization needs to commit itself to. But once done, ERP can be a powerful ally to it and vice versa. So if you already have or are planning for an ERP implementation, see how best you can derive benefits by examining your processes to eliminate waste and get leaner in the process!

March 10, 2009

When do we re-implement instead of upgrade?

Especially when the effort/cost required for both the options is approximately the same? If we were to assume the upgrade is from any of the 11i versions to R12, what are the key factors which will help us reach  a logical conclusion on this topic?
Two sides to this debate would be:

A) in favor of re-implementation (to avoid pain of resolving upgrade issues)

B) in favor of upgrade (to leverage Oracle's upgrade path and support)

To start off this thread, my starting comments in favor of option 'A' are:

Re-implementation provides more opportunities as listed below:

- get rid of old transactional data

- better control over golive cut-over

- less risk/dependency on DBAs/Oracle

I invite your thoughts on either of the above mentioned options.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter