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

« December 2008 | Main | February 2009 »

January 30, 2009

Driving Operational Excellence using Oracle Mobile Supply Chain Applications

Oracle Mobile Supply Chain Applications architecture empowers users to achieve new levels of productivity and accuracy. At the same time flexibility of this module along with features of hand held devices available in market makes the system extremely easy to use. Functions required for all transactions can be performed either using RF scanners (with barcodes) or through an Oracle form on hand held device.

Following are some of the key benefits which drive Operational Excellence by implementation of MSCA (Mobile Supply Chain Applications) are:

  • Reduce data entry errors and data entry time by use of Barcodes
  • Reduce labor travel time by transacting at point of use
  • Real-time data availability and validation

MSCA comes with standard screens on hand held devices for doing receiving transactions, manufacturing transactions, shipping transactions, inventory transactions and quality data entry. Standard MSCA screens will have a lot of fields which may or may not be used by an operator. It is one of the critical steps in an MSCA implementation to identify in each transaction screen which fields are required and which ones can be removed. MSCA provides option to customize the screens and have only the fields required in a preferred sequence for transactions. This goes hand in hand with design of key documents used in shop floor like Work order, Receipt traveler, Pick slip and any other traveler used during transaction. On these documents identify the key fields which are used for data entry and barcode them.

Oracle Warehouse Management module can be implemented in addition to MSCA to write additional rules which will optimize the travel time and further improve Operational efficiency. It also supports cross docking, flexible label printing, task assignments and LPN (License Plate Number) support for transactions. One of the prerequisite for implementing Oracle Warehouse Management module is using Stock locators and implementation of MSCA. Hence make sure if MSCA is implemented as standalone module locators are enables.

 

Should Hi-Tech Manufacturers increase outsourcing in these times of recession?

Let us examine the business drivers of a typical Hi-Tech manufacturer. Hi-Tech manufacturers are driven by the main factors of innovation and new product innovation, which are becoming increasingly evident now in the times of global recession. The Hi-Tech industry is characterized by declining product life cycles, falling prices which have an impact on any investments by these companies into any new machinery or new manufacturing technologies. Outsourcing provides the answer in such circumstances enabling these companies to push such risks on to their outsourcing partner.

Thus the following factors will determine the need for more outsourcing:

1. Cost : It is widely seen that there is a trend to move production  of non-core components and products to cheaper countries like China, Taiwan, India, etc. since it provides a significant savings in costs. The improvements and predictability of logistics have helped a great deal to encourage companies to take this step.

2. Flexibility: In these uncertain times the manufacturers would not like to invest in costly machinery to manufacture products which have short product life cycles and which may obsolete is a short period. Also the company would want to concentrate on their core competencies and outsource all other non-core activities.

3. Special Skills & Tools: This helps the companies to engage outsourced partners and leverage special tools and special skills that these outsourced partners have. This helps the Hi-Tech companies since they do not have to invest on these tools and developing such skills in their workforce. 

4. Responsiveness to Market: As mentioned before, the Hi-Tech companies work on very short time to market cycles and outsourcing helps in reduction of the NPI(New Product Introduction) cycle by leveraging the competencies of the outsourced partners to deliver components at a much faster rate than is possible to develop in-house.

Finally, it is felt that outsourcing of non-core activities will increase which will help the Hi-Tech manufacturers derisk themselves from the current environment and help them compete in this uncertain market. A company that outsources has much to gain. Yes, there are risks. But if you are able to master outsourcing or work with experts who have made outsourcing a core competency, the benefits far outweigh the risks.

January 24, 2009

Demystifying Merchandise Accounts Payable

Merchandise Accounts Payable, a mouthful isnt it? This blog explains and simplifies the complex area of Merchandise Accounts Payable, often seen in Retailers or Wholesalers. It also presents a point of view on various Oracle Products and their fitment to this business area.

Retailers are companies that engage in sale of goods and/or services through established store fronts, physical or virtual. The key aspects of any retail business is having a wide variety of merchandise available through consumer friendly store fronts using mutiple channels of sales, online, physical store, Phone etc. Given this core aspect of merchandising, Retailers typically have thousands and thousands of suppliers that they source the merchandise from. In addition to the large number of suppliers, Retailers also have wide variety of supplying relationships, let us take a look at some common ones.

1. Manufacturers - Procuring directly from the manufacturer of goods/service.

2. Supplier - Often suppliers are engaged when sourcing internationally, these suppliers in turn have factories/agents through whom the actual merchandise is produced.

3. Exporters/Expeditors - These are accelerating entities within the supply chain, which retailers use to move the merchandise across geographies in a quick manner.

4. Raw Material Suppliers - These suppliers provided raw materials which then are routed through factories into finished merchandise.

A typical manufacturing unit would engage with a selected/approved vendor list, which makes managing the supplier base easy. But for retailers, who offer a wide variety be it Apparal, Electronics, Grocery or a mix of all, the complexity is multifold.

Not only is the supplier base large, the amount of Purchase orders and receipts created often run into millions per day! Given this huge volume, it is challenging to track what was ordered and what was received and hence decide what needs to be paid. This in summary is the core problem with Merchandise Accounts Payable!

Typically retailers go through a very complicated Invoice Matching process, wherein the Purchase Orders, Receipts and Invoices are iterated in a complex rules based matching process, and often five or six iterations are carried out before an Invoices is approved. Some of the rules are based on Payment Terms, Item quantities and Items.

Most retailers utilize custom applications for procuring merchandise, because of the high volume and store specific nature of the purchases, Oracle Retail Management System is often a system of choice for this procurement.  Inventory management is often the strength of Manhattan systems and other WMS systems.

This means that the eBusiness modules has to deal with the GL and AP processes, typically Invoices are imported after the Invoices matching is done, this matching is either done again in custom applications or using the Oracle Retail Invoice Matching solution, this is a new offering from Oracle.

Oracle AP is best suited to import the invoices and carry out the check printing/payment processing and post to GL.

Several retailers are trying to bring in the procurement and invoice matching solutions into Oracle eBusiness suite, but in my opinion the jury is still out in terms of proving this solution's effectiveness.

What is your take on Merch AP, have you seen similar challenges in other industries?

January 23, 2009

Are we there yet? R12 upgrade and Retailers

Continuing from my previous blog http://infosysblogs.com/oracle/2008/12/r12_upgrade_whats_in_it_for_re.html

Are we there yet? Has the time come to pick the R12 Version of Oracle eBusiness Suite, it has been on the market for more than two years now, bugs have been reported but stability seems to have been achieved, let us look at what the version offers for Retailers as the dust on the product launch settles... 

Two years huh! How many clients with older versions know that, or really think about it?

Very few i think. Most of the organizations are still viewing R12 as an entry to Fusion enabled applications that are not yet stable. While there are the usual set of bugs, but the latest 12.1 version is getting stabler. Oracle has also come up with several Process Integration Packs, which makes the arduous task of integrating the ERP packages with other products come true. Process integration packs have been built using SOA fundamentals as well.

Shifting gears, Retailers are in a tougher situation now than they were last year, some were struggling even when the times were good, excess stores said some, bad assortment said others, but now everyone is focussing on the dropping consumer confidence as the reason. Added to it, traditionally retail investments into systems have been low and enterprise applications are viewed as assets that need to go through the typical seven year depreciation cycle before upgrades are planned. 

Putting two and two together,is this any time for upgrading to the latest Oracle ERP platform, isnt it more expensive? With support for the existing going getting stopped,

I think so. 

I also think it is no longer a matter of When? but more of How.

There are three basic models of implementations currently in vogue in the market

1. R12 for Master Data Management, with the 11i version continution to operate with a phased migration into the R12 version.

2. Upgrade to R12 - Technical at first and then Functionality implementation rolled in later.

3. R12 Implementation - Business Process reengineering combined with newer functionalities of R12.

What has your experience been, have you seen any other models of implementation? Has your project implemented any other flavor, let me know!

 

January 22, 2009

Quality and Liquidity

Very often we see the Terms Quality and Liquidity used interchangeably with Products or Services offered.

Although never directly related these terms are something which is heard everywhere on a day to day basis At one point of time you have the Customers talking about Quality, and the other part you have the Stakeholders discussing about Liquidity.Let us try to understand these terms and find out whether we can relate these terms and decide if ultimately Quality turns to Liquidity.

What is Quality?

ISO 9000 defines quality as “Degree to which a set of inherent characteristic fulfills requirements.". The standard defines requirement as need or expectation

American Society for Quality definition lays quality as "a subjective term for which each person has his or her own definition. In technical usage, quality can have two meanings:

The characteristics of a product or service that bear on its ability to satisfy stated or implied needs

A product or service free of deficiencies

Individuals and Organizations of all types and Sizes have always realized that their main focus must be to satisfy Customers

Two Questions that are put forth are

Who are the customers?

When are they Satisfied?

Customers are anybody to whom Products and Services are sold. Customers are satisfied when they get what is needed when it's needed. One should never assume what a customer needs. History in the Market has seen Products been launched and failed customer Satisfaction.

What is Liquidity?

The degree to which an asset or security can be bought or sold in the market without affecting the asset's price. Liquidity is characterized by a high level of trading activity.

The ability to convert an asset to cash quickly. Also known as "marketability".

In Short Liquidity means the capability of a product or an Asset to be sold rapidly in the market. The key consideration for Liquidity is that there are ready and willing buyers and sellers for the product at all times.

In the coming notes let us try to discuss and find out whether quality really impacts liquidity.

January 18, 2009

Is Pull Production the final word?

Typically when we talk about improvements on the shop floor, we hear a lot about Pull Production. Originating from the Toyota Corporation, pull production is a process that aims to arrange an organization so that customer preference or orders are what cause materials to be "pulled" through a system.

 

Well this may work well in case of a new manufacturing plant provided there is same kind of discipline on the shop floor, this type of production runs into roadblocks in case of remanufacturing where salvaged components go into the final assembly.

What makes remanufacturing unique is the variability of the Bills of Material structure. In one of my earlier blogs, I had introduced the concept of ‘Replacement Factor’ which is a measure of the quantity of new components for manufacturing the final assembly. With an ever changing Bills of Material structure owing to the usability percentage of the salvage component, a pull production will lead to over/under issue of components for each job. Issuing more percentage of salvage components in a bill where the replacement factor is high will lead to a favorable material variance while the exact opposite case is going to give a hard time to the accountants trying to explain the variance. And to add to this misery is the changing price of the new components on the Purchase Order.

 

In light of the above circumstances, it makes business sense to move to a Push kind of scenario where the floor issues the material to the job based on what is issued from the store. A typical problem arises because shop floor operates on a Kanban system and does not care to which job the material is issued to. At the end of the day we only need to ensure that all the issued material hit the books of the same product line.

 

Standard ERP packages expect issuing a component manually for WIP Supply Type ‘Push’. Due to resource constraints it may not be always possible to do this transaction at the shop floor. A workaround for this is to develop a custom component which will take all the issued components and issue it to the first open job of the day automatically. It does not matter if there are more open jobs because ultimately at the end of the day when the jobs are closed, it should hit the appropriate WIP accounting class.

 

There are certain shortcomings of this solution viz. this is going to cause problems if some components are pull while others are push. And on the shop floor, Joe the tugger should know exactly where to drop the material on the shop floor.

January 9, 2009

Year 2009 and Oracle Business Intelligence

With the dawning of the year 2009, the Business Intelligence pundits have started making their predictions on how the BI space will look like in this new year, especially in the given economic climate. I have read through a lot of such predictions and outlooks in most of the leading websites and analyst reviews. One theme is where most agree and that is better use of the platform and trying to tap into hidden capabilities of the existing BI platforms in order to get an insight into the organization’s bottom line and spent. I had as well highlight on the same in my last blog that BI is going to be a key enterprise instrument to stay afloat in the changed business scenario.
Keeping the current situation in mind we would like to wonder on what would be Oracle’s game plan in 2009. Based on my close interaction with this technology and Oracle as an organization during the last one year, I see Oracle playing the BI game in four to five broad areas

  •  Packaged BI: Oracle has tasted success with its BI Applications and is the undisputed leader in the space as of today. While most of the modules today cater to integrate ERP analytical functions, it has only a few industry verticals that it caters to. My thinking is that Oracle would come up with a few modules with in its packaged BI offering mapping to certain niche industry verticals.

  • Consolidation: Years 2005 to 2007 were years of acquisitions and year 2008 is where Oracle started its consolidation with broadly creating its EPM and BI roadmaps. The same would continue with the much awaited 11g release where the Hyperion BI System 9 is completely fused with OBIEE. This would be the birth of a new BI product in the market place and a real ‘fusion’

  •  Marriage of the ETL and ELT: This is something I am waiting for to see the final product resulting out of the marriage of Oracle Data Integrator and Oracle Warehouse Builder. As per Oracle’s product road-map this is where the ETL road map is heading and with the current situation where the market is looking for the best of all the worlds in the ETL space, Oracle may release a beta version of this product earlier than we would have thought. This is another ‘fusion’ that  might see light sooner than expected

  • Stronger Positioning of Data Miner: This is an application in a BI suite   which possibly has been very less talked about, leave alone used. It is through a Data Mining technique that an Organization is really able to use strategic benefits from its Business Intelligence investments, the rest is largely tactical. And it is a bit of shame that these tools are never used to the full potential. In the current climate, we could possibly see a stronger demand of the Oracle Data Miner and my belief is that Oracle would also come up with a stronger positioning of this product

 

January 7, 2009

Beat the competition with speed to market

Impact due to reducing product lifecycles and the need for speed and collaboration

In this Era of Innovation,the latest gadget becomes obsolete within no time. Better products come to market at cheaper prices and/or with higher value. The result is shorter product lifecycles.

The main effects of shorter lifecycles are:

  • Need for New Product Introduction(NPI) at shorter intervals – speed to market is the only way to beat the competition
  • Focus on cost effective / high value products
  • Innovation in processes

The key enabler to achieve the above is

  • More collaboration between stake holders.

A typical lifecycle involves the phases of Concept, Design, Prototype, Manufacturing, Service and Retire/Obsolete. Or in simple words…developing a product (Physical Development) and Manufacturing and selling it. Collaboration is done at two main levels as far as Product Lifecycle Management is considered.  While Design Collaboration tools cater to the need of Physical Development of Product more effectively on a real-time basis, the Collaborative Product Commerce tools can cater to entire NPI from concept to Retire.

Design collaboration tools enables companies collaborate between design teams across geographies and with different vendors. These tools offer real-time shared work- spaces across geographies. Design is validated using high end analysis tools in order to eliminate errors in prototyping stage.

Design collaboration and validation tools ensures almost perfect product but given that fact that on an average only 30% of the new products succeed, care should be taken to ensure the product launched is successful in market. Collaborative Product Commerce (CPC) tools ensure that product launched is successful by collaborating with all departments and partners thereby ensuring availability of right resources. CPC tools also have archive of all relevant details of previous new product Introductions – this archive helps companies to reuse data already available and to avoid mistakes made in the past.

The other dimension to be considered is the need for customized products. Companies are forced to move from traditional ‘made-to-stock’ model to ‘build-to-demand’ model. This demands an efficient customer-producer interface. To deliver custom products on time, Manufacturers out-source most of the components and focus only on their core product – modular manufacturing helps companies to cut costs and deliver on time, this again calls for collaboration with all the suppliers.

Thus, CPC focuses on the manufacturer’s core business of designing and building products. Manufacturers interacting with suppliers are not new but collaborating real-time on many levels is made possible by CPC tools. Manufacturers interact with both customers and suppliers to share early product concepts, designs and prototypes to develop a product that is manufacturable, satisfy customer needs and ensure timeliness to market. CPC is about applying technology to the entire product lifecycle process of designing, engineering, building, delivering, and servicing the product while applying technology to do it better, faster, and cheaper. CPC helps to evaluate existing business practices and introduce more efficient new practices. Also it enables sharing of knowledge within the company and also with partners and customers.

To conclude the demands of accuracy in design, speed to market, customization, and the need to manufacture using pre-built components from third parties means that cross-enterprise collaboration is becoming a necessity for manufacturing success.

(With technology inputs from Aberdeen Group - www.aberdeen.com )

January 2, 2009

Oracle and BEA- The Real Fusion

Three years back Oracle concocted Fusion middleware to integrate and merge all its key enterprise applications into a high quality Fusion Application.Who would have thought that even Fusion middleware will undergo further Fusion?Acquisition of BEA Systems last year has enabled Oracle to position itself as the strongest in providers of middleware and java technologies for enterprises.

Last two quarters we have seen a sea change in Oracle’s middleware strategy for most of its customers. Ambiguity and turbulence generated in customers and solution providers due to overlapping seem to be fading now. 2009 is expected to bring better understanding of the strategy of Oracle and its right adoption. 

Oracle Fusion Middleware will exhibit a new face with its next version (11g) planned to be rolled out by mid of this year. It will have blended offering originating partly from BEA and partly from Oracle portfolios. BEA's Web Logic Server and Aqua Logic BPM combined with Oracle's BPEL Process Manager and Web Center will be flagship products for the new OFM stack.

 Oracle has announced that all pre-acquired products will be supported for the next five years, allowing customers to leverage existing investments. Most enterprises, using BEA or Oracle technologies need to know how they are impacted by Oracle's new technology road map. There are no radical changes needed, but next investments will need to be planned meticulously.

Next target for Oracle is to have all middleware products upgraded to be "hot-pluggable" with the ability to run on multiple Java application servers, such as those from competing vendors like IBM to support multiple infrastructures. Many components for example, BPEL PM, Coherence, Top Link, and J-Developer are already hot-pluggable. However to make BEA products like Aqua Logic Service Bus work on application servers other than Weblogic will be a daunting task.

If one were to ask Oracle on the top three motivating factors behind the acquisition honest answer would be - increase in market share, customer base and entry in Chinese market. The bold decision made by Oracle to drop homegrown products, opens easy opportunities for competitors to coax customers away from Oracle/BEA but many believe and are sure it would only reinforce faith of its customers in Oracle in providing best in class products to them.

According to Gartner “Investments in Oracle's middleware are low-risked”, Acquisition of BEA Systems will not disrupt OFM's architectural foundations or technology direction. Both are strongly founded and nurtured in Java and they support the same set of fundamental standards (XML and SOA). 

The real fusion has begun now heralding a new powerhouse.

I would like to hear your views if you are impacted by one of the biggest mergers in IT middleware camp.

ERP for SME – why and why now?

For many the word ‘ERP’ conjures up an image of an extremely high priced and complicated set of applications that only a few understand and whose services only big organizations can avail. Over the last many years that I have been working as an ERP consultant I have come across many such instances wherein the managers of SME company are wary of ERP and ask ‘Can it be implemented for a small company like ours?’

With the present economic recessionary environment Small and Medium Enterprises (SMEs) which have been running on very thin bottomline must look at various avenues to reduce their costs and increase the operational efficiencies. The business applications provided by various ERP packages have over the last few decades evolved from just being a transactional system to one that provides functionalities built around industry specific best practices and standards. Notwithstanding the benefits an ERP may provide the IT and business executives of SMEs face the challenge of convincing the stakeholders that this is an investment towards an ability that provides better productivity which would help lead to better profitability, market share and / or customer service.

The cost of implementing ERP; which has traditionally been assumed to be highly exorbitant, is being driven to lower levels based on newer implementation approaches being evolved by seasoned Implementation Partners or System Integrators. Also the investment from various ERP product vendors to include industry specific best practices has made the advantages of implementing ERP far outweigh the expense, and ERP decisions can now be considered to be are a ''lower-risk high return'' option.

Inspite of the present economic scenario mandating SMEs to adopt packages driven by best practices and low risk high returns possibility to increase their productivity SMEs are reluctant to invest in an ERP package as they are not too sure about the following: Implementation Time, Ease of usage by its Employees, Flexible for changes and ofcourse Total cost of ownership (TCO).

Implementation Time:

Over the last two decades where more and more large scale companies; especially in developed markets, have implemented one or the other ERP package, the experience and insight gained by both Implementation partner and system integrators has made them focus on reducing the total implementation time of the ERP solution. The industry specific process templates; which are the outcome of the extensive experience gained by seasoned implementation partners and developed by their synergic partnership with product vendors, help to greatly reduce the time required to evolve the baseline processes which translates to significant reduction in the overall implementation timelines. To be able to leverage the templates the SME should be flexible to change its present processes and adapt to the best practices offered by the standard processes. The benefit to be gained would be squandered if the SME chooses to customize the package based on its present processes.
This reminds me of a simile which one of my professors at b-school used to quote: He said that ERP is like a Jet Airplane leveraging which companies can fly instead of driving an old worn out car. But most of the companies after buying the Jet want to add headlights just the way they have in the present ‘car’, want to add indicators, horn, brake etc. and finally they turn a Jet into the same old car. This similie aptly sums the pitfall that SMEs must avoid while to not only have the best practices but also have a significant reduction in the overall implementation timelines.
I will be touching upon the other points which bother SME in my future posts to this blog.

Operational Excellence Metrics – Implementation Considerations

Past couple of decades manufacturing organizations have focused on improving the quality of their business process to achieve operational excellence. ERP implementation is seen as an opportunity to re-engineer the existing business process, define / review Operational Excellence Metrics and ways to measure these metrics.

Following are some of the key operational excellence metrics measured in manufacturing organizations:
  • Delivery to Request Date
  • Delivery to Promise date
  • Promise date to Request date
  • Lead time improvement (Internal and Supplier)
  • Product line returns
  • Field Warranty rates
  • Internal rework
  • Setup times
  • Scrap
  • Inventory Turns
  • Quality PPM

There are few prebuilt KPIs (Key Performance Indicators) which come as standard offering in any ERP applications and some will have provision to define custom KPIs based on the industry requirements. Oracle eBS provides Daily Business Intelligence modules, Standard Oracle reports, Discoverer tool and dashboards to measure and monitor some of these metrics. There are organizations which use tools like Noetix; which gives an option to build your own dashboard, or build custom portal / intranet webpage which pull data from a data warehouse or from ERP database.

Following are some of the key aspects required to design the operational excellence metrics:

Driver
Identify the driver for the metric; ask what you are trying to achieve by capturing the metric. For example Promise date to request date this is directly driving the Customer satisfaction. This may or may not be a key metric in a distribution / storage center where the key metric can be the turnaround time for order entry to delivery instead of promise date to request date. It is very important to identify the key metric which makes sense to the organization to capture instead of having all possible metrics available in the ERP application. Some of the metrics are driven by corporate standards and reporting requirements not necessarily driven by the ERP implementation.

Audience
Identify who will use which metric and how frequently the data need to be refreshed (daily, weekly, monthly, quarterly, and annual). Metrics can be grouped by departments like Shipping, Planning, Procurement, Finance, etc. for ease of distribution. Traditionally Data Analysts or IT department was preparing the data and graphs and presenting it to the business users. Now with the evolution of new interfaces like dashboards and excel file extracts users are able to directly pull the information and analyze. There are few metrics shared with external entities also like PPM which is shared with Suppliers.

Medium
Determine how the data will be distributed; it can be as simple as data extracted from database and sent in an Excel file, or sending the data in the form of a graph/ table by e-mail, Intranet website with spotlight charts and data tables, use of data analysis tools like Discoverer, displaying charts on notice board, displaying charts on each line in the shop floor, as a slide shared in regular staff meetings / newsletters. There is no single medium used as standard it purely depends on the type of metric audience.

Content
This again depends on audience; content should be simple and clear in projecting the progress. Content can be just data presented in a table or graph showing the progress. There are few metrics which need historical data to show progress like Lead time improvement, this drives the requirement to archive the data. Most of the organizations use a data warehouse to maintain historical data and use this to do analysis. For few metrics there is static data (like organization targets) also required and need provision for loading this data.

Operational excellence metric design is very important for any ERP implementation and this definition should happen early. Metrics should be clearly defined before start of the project to measure the benefits of implementation. It becomes even more important in the current recessionary times to improve operational efficiency by reducing cost, increasing Customer satisfaction and achieving operational excellence

Leveraging Oracle SOA For A Regional Health Information Organization (RHIO)

Details of the successful SOA implementation using  Oracle Fusion middleware for a RHIO.

Health Information Exchange (HIE) is a way to electronically make personal and medical information securely available among doctors, hospitals and other health care providers when it is needed for care. A secure electronic HIE allows patients to make sure their health information is available when they need it while seeking medical care or treatment. HIE enables authorized physicians and other health care providers to share a patient's clinical results across institutional boundaries.

Client utilizes a healthcare industry standard, which is based on XML, that could be easily consumed by other systems. Client also wanted to expose internal services encapsulating the data repository to external world so as to be easily consumed by other systems.

We have faced Various Challenges during the execution of the development phase.

Systems accepts and provide different versions of HL7 messages.
HL7 V2.X messages which the clinical system send are in pipe delimited format.
HL7 V3.0 messages which the client system accepts, are in XML format and has 2 different sections. The header part is in ebXML format and the body part in CCD/C32 format. The real challenge is to convert the Pipe delimited HL7 V2.X messages to HL7 V3.0 Message which is in XML format, without any data mismatch(This is so critical that data related to patient medical information).
Another target system accepts messages in HITSP C32 format and its response is in ebXML format.
Huge data volume, which has to be exchanged between systems in HL7 format, which resulted in huge performance flaw in SOA server and Java Heap error etc…
Issues with Jdeveloper while doing the transformation, as it was not able recognize the schema due to its complexity.
Developed Java API to convert the data body part of the HL7V3.0 Message to Base64Encoded format.
Oracle B2B is used for the trading partner Management and validation. The oracle healthcare adapter  provides,HL7 2.x in/outbound validation and translation to/from the native file format to an XML instance(ebXML for  instance).
Above all good team effort from principal architect to developer.

In 13 days the team was able to:
·Conduct 1st PoC demonstration with-in 6 days of kick-off for client  CEO & Chief Architect and their reaction - “…impressive…we didn’t think you could achieve that much in 6 days!” and did the final demo on 13th day and RHIO folks were impressed by the amount of work achieved in such a short duration
·Complete some of the most complex XML based HL7 Mapping, Transformation, BPEL Configuration, & portal component in just 9 days that typically takes weeks

 

January 1, 2009

Case for a unified efficiency metric

In the current business scenario, manufacturing businesses are under pressure to outperform the prevailing economic trend. There is a need for a broader organizational perspective/metric that needs to be taken into account. Without this, it would result in the transfer of, if not addition of overall ‘waste’ to the organization.

In the current business scenario, manufacturing businesses are under pressure to outperform the prevailing economic trend. This pressure manifests itself in the need to hold onto competitive advantage. This results in pricing pressures being applied from competition as well as customers. This need would also be prevalent for holding onto existing market share or preventing the overall market size from shrinking as well.

The challenges thrown strike at the following areas:
1. Reduction in cost
2. Reduction in lead times
3. Increase in product proliferation

The demand today is low lead time, low cost, mass customization. This is driving manufacturing firms towards tailoring product offerings knowing fully well that the offering may have an extremely short life cycle – during which they have to recover the development cost as well as corporate objectives of new product introduction. Thus a manufacturing firm is being further driven towards the aforementioned three points and the need to manage the same in the most efficient manner. The need for tighter control on these only seeks to enhance the need for higher real time visibility of data to drive more informed and responsive decision making. This also means an extremely hard look at the metrics to be considered for such dashboards. The measures as I see remaining as important could be grouped into:

  1. Availability Metrics eg. Resources and material, On schedule for activity fractals
  2. Productivity Metrics eg. Resources applied, Interactions made/Interventions required,
  3. Quality Metrics eg. Impacted overall cost of produce against budgets, Throughputs, Effective reduction in cycle time

The change(??) lies in the manner in which these metrics are analyzed. The viewing of these in isolation for a manufacturing process is what skews judgment on performance and could lead to erroneous decision making. These now need to be very tightly coupled with key performance indicators from other functional departments as well. The metrics that these tie into from an Order Capture and Sales perspective are as follows:

  1. Availability Metrics:
    1. Availability of personnel to process the order
    2. Time for making the available information to process the order to next stage
  2. Quality Metrics:
    1. Order capture scheduled ship date entry against published lead times
    2. Forecasting efficiency metrics – The approach needs to provide a higher emphasis on SKU based, margin driven system as opposed to an overall dollar, quantity basis.
    3. Pricing discipline metrics – Margins earned and actual cost of sales need to be evaluated here in conjunction with the operational costs for building and distributing the product.
    4. Expedite and Push Outs for planned orders
    5. Capture of expedite fee when scheduled ship date is under published lead time
  3. Productivity Metrics:
    1. Time to process an order
    2. Number of personnel needing to touch an order in its processing cycle
    3. Complete information availability cycle time for orders
    4. Number of changes to an order
    5. Number of interventions required/requests for information once an order is entered

Similar metrics could be looked at for the Picking and Shipping process as well. The overall metric needs to take the effect of the aforementioned into account when developing the same for the business.

The development of such a metric requires a cross functional approach in evaluating performance. The days of functional/divisional efficiencies being the factor to drive overall efficiency are now passé. The sum of efficiencies gained might actually be driving the overall efficiency of a process down. The metric to be applied needs to be much more inclusive.

In one of my assignments, the Engineering department in a bid to reduce the number of transactions performed, got consent for a process by which a lot of stocked subassemblies used on the floor were made phantom in the system thereby removing the part numbers in the system. The result of this was:

  1. Engineering had fewer ECOs to release
  2. Operations had a nightmare on their hands with regards to material availability, as though the item showed in stock it had actually been used in the subassembly which now was not being tracked in the system

Another example in this regard was the definition of On Time Delivery as a performance metric for Operations and Shipping personnel. Order Entry was expected to record the customer request date as the scheduled ship date. The consequence of this was the order entry team putting in dates as the customer requested perfectly – with little or no check on what the lead times for the products actually were. Operations team was reduced to creating a separate commitment metric which tempered the dates down as per the actual committed lead time for the orders. This was a result of elimination of the process of conversations with customers with the order entry team. The order entry team was now supposed to take orders on faxes thereby saving the interaction time. The absence of the interaction window, no association with overall metric were again shown to be the cause of what choice of metric in isolation could lead to.  

What emerges is departmental kaizens are good but unless there is a broader organizational perspective/metric that is taken into account, it would result in the transfer of, if not addition of overall ‘waste’ to the organization.

Simplistic as this may sound, the key lies in being able to put together what each department believes is the contributing factors and their weight age to the overall metric. Formalizing, tracking and actionizing the same diligently then become the next set of challenges in the evolution path of the firm’s quest to its objectives.

Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter