Yes, I am back again this time keeping up my promise for a deep dive (shall I say neck deep!) into specific areas for IFRS transition. Just thought it would perhaps interest the readers (if any!) if some ‘hot’ topics laced with factors behind formulating  policies falling in ‘Accounting’ / ‘Information Systems’ (our narrow interest is Enterprise Applications!) are provided.

With the above background, let me get into ‘Segmental Reporting’ – a very common area (even without IFRS!). At the outset, it is good to note that IAS 14 deals with this subject and  AS17 – is the corresponding Indian Accounting Standard already  in force for certain companies.  Also, much to the relief of  ‘Accountants’ broadly there are no major variances between IAS14 and AS17 –  On the lighter side, feel – if one reads through the accounting standards – hardly 10% will be understood in the first few readings! (10 times taxing to first understand and xx??[God knows how many?] Times for implementation!!). However at the end, there is a larger intent to analyze financials to proactively assess if the health or intended moves of an enterprise are in the right direction adding investor value.

Now here is what IAS14 mandates – Looks pretty simple, till one has to implement!

• An entity reports information for ‘Business Segments’ and for ‘Geographical Segments’, indicating the types of products and services included in each reported business segment and the composition of each reported geographical segment. (One of these segments will be ‘Primary’ and the other ‘Secondary’)

• A set of reporting requirements – listed below for ‘Primary’ / ‘Secondary’ Segments so identified.

Already panting? Ok! Understand – here are a few breathers:

• Standard (mercifully!) applies only to entities whose shares are listed in Stock Exchange(s) or which are in the process of issuing the same for eventual listing:

• Don’t be overjoyed!! – Indian Accounting Standard is much more extensive in its coverage as it prescribes some additional class of companies or criteria for coverage (Ex. Banks and Insurance Companies, Entities having a Turnover of more than Rs. 50 Crores – (Approx. $10 Million). Borrowings in excess of Rs. 10 Crores (Approx. $2 Million), Holding / Subsidiary of any of the companies covered by AS17.

• Disclosure requirements arise only when the segment revenues earned from external customers are in excess of the prescribed threshold limit of 10% of the Total Revenue (Both internal and external).  – A minimum of 75% of the total revenue should be covered by segment reporting failing which additional segmental classification needs to be included until this limit is met!

I can already hear a few loud voices – how to identify ‘Business Segments’ or ‘Geographical Segment’ –

• IAS14 in my view lacks clarity [“The source and nature of the entity’s risks and rates of return determine whether the primary reporting format is business segments or geographical segments. This is usually identified by the entity’s internal organizational and management structure and its system of internal financial reporting to senior management.]

• AS17  provides some more guidelines for ‘Business’ classification based on Nature of Products and Services, Production Process, Type of Customers, Distribution Channels, Regulatory Environment  and for ‘Geography’ based on Similarity of Economic and Political Conditions, Relationship between Geographies, Proximity, Specific risks associated with a Region, Exchange control regulations etc.,

I am aware that this article has probably crossed reasonable limits. However, all the erudite readers will be quick to realize:

1. Aspects related to classification of ‘Business’ / ‘Geography’ segments (and possibly additional segments!), how to deal with financial elements that can’t be directly ascribed to specific segments (what kind of allocation rules etc., can be logically followed)   are all matters which are internal to any organization in which Professional Audit and Accounting Firms   are best positioned to assist in formulation of proper accounting framework for transition and then to ongoing compliance.
2. IT Service providers like Sierra Atlantic Inc., – on the other hand can consider the inputs for ongoing compliance arrived in Step 1 , evaluate gaps in the existing ‘Enterprise Applications’  configurations and come up with a sequence of steps for best possible fulfillment – i.e.:

• Upgrade to Release 12 Vs Re implement – Examine the flexible ‘Sub Ledger Accounting’ [SLA’ framework provided], other options [Ex. Multiple transaction types, Capturing mandatory additional information during transactions, organization structuring etc.]

Hopefully, readers now see the difference that I briefly dwelt upon in my first dialogue on the subject!  Before I conclude, here is another  compliance rider of IAS14  – Once a segment is reportable, in the next year even if it goes below the threshold limit it continues to be reported  and likewise if you have new reportable segment information that emerges in one year then you better provide previous year comparison as well !! – Accountants always on the receiving side! Icing on the cake, I suppose??

By for now, and hope to be back soon with insights into yet another topic.

After a long gap, I am once again continuing my earlier OPM upgrade blog series. Carrying on from where I left, OPM upgrade is definitely different unlike the other module upgrades in Release 12+. This is due to fact that Oracle has introduced much awaited inventory convergence in this version. Before we jump on to the inventory convergence, associated impact and some of the challenges which customer might face, I would like to share some details on the upgrade steps for an OPM customer. For OPM customers, there are some additional steps to be performed during the upgrades. Please refer oracle support website for details on OPM migration. Usually upgrades are performed through various iterations and each upgrade would have a few sub-phases, ‘pre-migration’, ‘inline migration’ and post migration’. To complete iteration these sub-phases are followed by additional functional configurations, unit and integration testing. While these iterations are in process, another team in parallel would work on re-certifying CEMLI’s to work in the new environment so that when the final system integration testing is being performed, all the pieces of an upgrade puzzle can be tied together.

Going little deeper into upgrade migration steps, there are a set of pre-determined activities which are performed, but the key lies in pre-migration steps which involve convergence migration setup and post migration steps where the transformation to new model happens. Convergence migration setup form facilitates customers to review their current setup related to companies, organizations, warehouses, items, batches and quality data. Especially in the first upgrade iteration, this phase is the most critical phase where a  high degree of collaboration happens from the customer and vendor team. Hence, we usually recommend a higher time allocation from the customer team during this phase of the project. The setups thus finalized, will determine the new model. Some of the validations which happen are inventory validations, process execution batch validations, quality validations, MAC to SLA model validations etc. Brief details on each of these validations are available in OPM migration guide.

Our experience in some of OPM upgrade cases indicates details provided in migration guide are not sufficient, for example, how the status control of OPM is handled in discrete with new on-hand material status control or how is ISO handled with upgrade, there are some challenges in handling non-inventory items with new model, dual UOM control and deviation issues affects transactions in new model, negative inventory issues in new model, why all the attributes are not migrated during upgrade. While these are some of the issues, there are many more that affect the overall upgrade activity and indirectly impact solution acceptance and user experience with new solution. In addition to this, especially in the case of OPM upgrades, the volume of data in specific functional areas affects the overall upgrade blackout time and needs detailed evaluation before any plan is finalized. This is where our deep-domain expertise in the process manufacturing vertical can help our customers.

Let me start the dialogue with a brief on a contemporary topic of widespread interest, from regulators to organizations, accountants, product vendors and finally IT service providers ie. ‘International Financial Reporting Standards’ – commonly referred as IFRS, administered by “International Accounting Standards Board” – IASB.

Not to delve too much into the history, most of us are aware  IFRS in general,  through various ‘Accounting Standards’  mandates a set of principles, practices  and disclosure requirements that organizations are required to follow with a general intent to promote uniform adoption of accounting practices, laying the foundation for significantly enhanced financial data quality, thereby enabling all stakeholders in improving the quality of analysis and reflecting  a truly ‘Fair’ view of the financial statements. It is pertinent to note that most of the advanced (USA, UK, Canada) and developing economies (India, China) are either in a stage of transition or in the first stages of active implementation of this ‘convergence’.  Over the years accounting bodies around the world, have prescribed and administered a set of (Local) Accounting Standards for adherence by entities  operating within their respective jurisdiction which,  in most cases ,vary with the  IFRS standards  requiring ‘convergence’  during IFRS adoption.

With the above backdrop, as I see, every IFRS ‘convergence’ needs to address the following aspects i.e. :

1. 1. ‘Accounting’  – analyzing the impact of IFRS standards vis-a-vis the local standards –  to account for the net financial  impact of the variations, if any,  in the financial statements of the first  period in which such convergence is mandated. – Ex. In India, organizations moving over to IFRS standards in March, 2011 will have to undergo this exercise as on the first reporting date – i.e. 31^st March, 2011 and also for the previous  year(s) comparative financial data required to be provided.  [Significant impact areas are – Recognition of all assets / liabilities arising out of financial derivatives, recognition of liability on defined benefit plans,  warranties, guarantees etc.,]   In my view, this is largely a ‘one time’ exercise which will set the base for new/ changed  accounting requirements.

1. ‘Information Systems’ –  Essentially this is a byproduct of the previous step and presents a need to assess the landscape of ‘Enterprise Applications’ to devise strategies for continued compliance.  (in Oracle eBS parlance, options for changes to accounting structures, recording of transactions in General Ledger,  examining edge applications in Oracle – E.g. Financial consolidations using  tools like Hyperion)  are examined.

• Here is where IT service providers with deep insights into specific Enterprise Applications, can provide sound counsel and present workable strategies for a seamless transition in  double quick time!

Before it gets any longer, bye for now! As I close, I wish to mention all such ‘convergence’  stem out of the increased thrust on the overall ‘Governance, Risk and Compliance’ [GRC] as ‘accounting innovations’ are on the rise?? (any guess??)

In the forthcoming editions, I will cover insights into specific areas of IFRS and then extend reach to GRC.

Production scheduling has traditionally been considered as a manual and iterative exercise by shop floor planners who are required to continuously balance the material and capacity constraints.  This has often led to poor manufacturing performance, excess inventory buildup, un-planned downtimes and eventually resulted in shop floor nervousness. With the ever evolving supply chain strategies and demand driven production methodologies, finite production scheduling is being seen today as a means to achieve manufacturing excellence and business transformation.

So where does production scheduling fit into the complex equation of Supply Chain Planning?

We all know that material moves through a supply chain from Buy->Make->Sell, where as the planning activity focuses in the reverse direction Sell (Demand) -> Make (Manufacture) -> Buy (Supply). Each of these individual activities can be broken down to their sub levels but as we can see, Make (manufacturing) is where the core production activity is centered in a typical supply chain. Production planning amounts to what and when we need to manufacture in order to effectively meet the customer demands where as Production Scheduling is the actual process of deciding how to commit resources between various possible tasks. In a nutshell, if you have planned to do multiple tasks, you cannot do all tasks in one go – you have to schedule and synchronize them. The end objective of Production Scheduling is to maximize through-put & customer service levels and at the same time minimize downtime, inventory, changeovers, overtime etc. All this leads us to believe that in order to have a perfectly synchronized manufacturing eco system, today’s shop floor planners need efficient and cutting edge scheduling tools.

Oracle’s best of breed Value chain planning solutions (VCP) address a wide array of supply chain planning challenges in today’s world.  One of the key elements of Oracle VCP is Production Scheduling (PS) ,which is a finite planning and scheduling tool that was originally part of JD Edwards which after the acquisition by Oracle, has been seamlessly integrated with Oracle E-Business Suite. Oracle Production scheduling solution comes with feature rich functionalities that would make the life of a shop floor planner more comfortable. The planners can now not only make informed decisions but also align the manufacturing activities to meet the organizations objectives. Some of the high level features of Oracle Production Scheduling (PS) are –

1. Graphical and intuitive UI with high level of flexibility built into it such as Gantt charts, Multi-Capacity Resource views, graphical routings Etc
2. Analytical view with drill down to root cause analysis of constraint violations.
3. Ability to model complex what-if simulations and compare against a base plan
4. Automatic floating bottle neck detection and rescheduling
5. Key Performance Indicators (for e.g. order fill, line fill, Inv. Turns, resource utilization etc)
6. Out-Of-Box integration with Oracle E-Business Suite

Oracle Production Scheduling supports both discrete and process mode of manufacturing. PS can be implemented either in a standalone mode or in an integrated mode with Oracle EBS. PS requires very minimal setups from an Implementation perspective and can be deployed almost immediately.

This is a brief introduction to Production Scheduling (PS) module. In next discussions I would be giving a high level overview of PS’s close cousin – Oracle Strategic Network Optimization (SNO).

In the fascinating world of Oracle applications, the process manufacturing industry is broadly categorized as ‘Discrete manufacturing’ and ‘Process manufacturing’. Technically, there are quite a good number of differences in the way one looks at each of these manufacturing streams. For ease of understanding, in discrete manufacturing one assembles to make things, while in process manufacturing as the name suggests, one processes to get some output. If we dig deeper into the process manufacturing stream, it typically deals with mixing, blending to yield products, co-products and sometimes by-products. Another easy way to understand this is that in the process manufacturing industry, the raw material consumed will eventually lose its form to yield a finished product. Rarely will you come across a scenario where the finished product can be reverse engineered to yield the raw material. This is one major difference as compared to discrete manufacturing where the finished product can be de-assembled to get the components back. The final product characteristic is determined through a formula, recipe and routing along with different process instructions and parameters being maintained throughout the process.

At a broader level, some of the sub-verticals of this industry include Chemicals, Metal and mines, Food and Beverages, Pharma etc. There are a few more like Glass, textile, paper manufacturing etc, which again can be broadly categorized under the above or can be a different category by itself. Within each of these sub-verticals, there are categories like the Food and beverages have dairy, chocolate, juice, meat and poultry etc. as categories, whereas the Chemicals have streams like paints, fertilizers, specialty chemicals, glass etc. This list can be endless, but the common thread across these verticals, sub-verticals and categories is that there are formulas, recipes, operations, routings, batch processing yielding products, co-products and by-products, measuring product in multiple unit of measures, quality grade and status, ensuring traceability of material across the supply chain.

I have been fortunate enough in my working career to be associated with these different verticals directly or indirectly. Every association has resulted in some new learning about the process manufacturing stream, with each vertical/sub-verticals having a few common challenges like:

-          Ingredient characteristic variability, which affects product quality

-          Process control and stability to yield consistent product quality

-          Visibility and traceability across the supply chain

-          Cost and margin pressures

-          Process cycle time and shop-floor control

-          Non-conformance and deviation

-          Regulatory Compliances

Right from the initial process manufacturing solution GEMMS, till the recent Oracle Release 11i, most of these requirements have been addressed directly or indirectly. With the introduction of some new features in Oracle’s R12 OPM solution and a combination of new modules which are now available for OPM customers, most of the above mentioned challenges  can be addressed quite comprehensively.

Today I would like to conclude here. In my next update I would initiate a discussion on R12 upgrade as an option for any existing OPM enterprise on 11i or earlier version, typical challenges, some best practices and then move on to the new features and modules available for OPM enterprises.

Find Part 1 of Pankaj’s series here.