ERP Resources

Appreciation that I received from an internal customer....

2012-01-18T09:28:00.001+05:30

This was an appreciation mail that I received from an internal customer on how I helped resolve a key issue.....

----------------------------------------------------------------------------------------------------------

Just a quick note to sing the praises of Ramaswamy. This escalation was pretty out of the ordinary in the way it was managed outside of the process, and with many, many confusing emails and issues. As the manager involved, it was not until I received Ramaswamy's description and detail of the situation that I had a clear understanding of what had happened, and what were the real issues. Within a few hours, we had resolution to the single bugged issue. This was due to Development's ability to quickly assess and provide a fix, but also Ramaswamy's constant vigilance and project management to see the fix tested and applied at the customer site.

I am a certified Project Management Professional, and I can assure you that few people know how to manage projects like Ramaswamy did yesterday. As if that wasn't impressive enough, he did all of this with very little sleep, and such a big-hearted enthusiasm for the customer and Oracle, that he actually made this escalation fun to work on.

I hope that there is a gold star for Ramaswamy and the hard work he did on this project, and I hope that we have the opportunity to work together again in the future. Truly, thank you for the great work!

Managing from offshore - lessons

2011-12-10T06:45:00.000+05:30

I am currently the PM of a project with the following profile.

The customer is a state government of a State in Mexico in the Central - North of Mexico
The Customer has given the contract to a Mexico Company. The Project Manager is working out of Mexico City which is to the Central - South of Mexico
The DBA is working out of Chile
I am working out of Bangalore, my SCM team is in Bangalore and the Fin and Development team is in Hyderabad.
My team speak English, the customer speak Spanish
True example of On-site - Off-site - Offshore model

While working on the project, we learnt some interesting lessons.

Plan for more time. For example every communication should go through English - Spanish - English cycle making the communication to take more time than normal. So plan for more time in your project plan.
Communicate as much as possible in English. Let the translator worry about communication.
While reading mails from the customer, be aware that the original communication was in Spanish and that the translator could have made some errors while translating the same to English
Ask for and deliver screenshot based communication always. More the pictures, less the confusion !!
Stick very closely to process. For example, if you have decided that once a report moves to Production, any errors should be handled by customer, always stick to this. Do not compromise on this. In a normal project, you can take these things in a one-off manner. However, in a project of this nature, you will never know what is the kind of expectations that you are building into, once you move out of the process.
Visit On-site at least once to understand and build rapport with the customer and the On-site PM. Budget this into your proposal.
Since Latin America is 12 hours behind India, ensure to set in place a process for working at customer's timeline. You may have to give shift allowances to your team. Factor this in upfront in proposal.

I will add new lessons as and when I remember them. In the meantime, the floor is open as always. Any other relevant comments or experiences that you want to share?

'Partha System' of accounting

2011-11-20T22:24:00.000+05:30

Many marvari companies in India follow what is known as 'Partha System' of accounting. This involves tight monitoring of costs, cost elements and their variations and ROI based on Cash Flow. I am looking for some documentation on this system. Anyone has any material on this?
Can you post the links if you have any?

The Bank Account Model in R12

2011-11-11T08:02:00.001+05:30

I have been working recently on R12 financials and I came across an interesting insight.
The problem faced by customer was as follows.

The user created a bank account in Operating Unit 1 / Legal Entity 1.
They now navigated to Operating Unit 2 / Legal Entity 2
The Bank account created in OU1 / LE1 was visible and editable in OU2 / LE2

This was a major audit violation.

As you know, Oracle has come up with significant changes in the design of R12 which are aimed to handle the requirements of Shared Services. For example, a payable unit in India can handle the payments of multiple Legal Entities and Operating Units.

One of the design approaches in R12 (to handle Shared Services) is to use MOAC.

The other relates to Supplier Model

And another, most important change, is relating to Bank Account Model.

In 11i, Payables Owned the Bank Accounts, in R12, the bank accounts are owned by Cash Management

In 11i, the bank accounts were at the operating unit level, in R12, they are at the Legal Entity Level.

If Bank accounts were controlled at the Legal Entity Level, how come the user is able to see the bank accounts created in LE1 when working on LE2?

This question baffled us for some time. However, finally we found the answer.

The access control in R12 is not only at the Legal Entity Level, it is at the User - Legal Entity level.

The following attached diagram will help you understand this concept better.

As this diagram shows:

1. Bank Account 1 is created under LE1 / OU1

2. Bank Account 2 is created under LE2 / OU2

3. User 1 has access only to LE1 / OU1

4. User 2 has access to both LE1 / OU1 and LE2 / OU2

5. User 3 has access only to LE2 / OU2

6. User 1 can access / modify only Bank Account 1

7. User 2 can access / modify both Bank Accounts

8. User 3 can access / modify only Bank Account 2

Your feedback? Experience?

Loading Historical Data in ERP

2011-11-09T10:00:00.000+05:30

Siva, a reader of this blog asks,

"What is the problem with loading historical data in Oracle ERP? Why is it discouraged?"

As I answered to Siva,

The reason dumping historical data into Oracle EBS is discouraged is due to the following reasons.

1. Historical data do not have any transactional significance. All the transactions related to this data is completed and closed. So there is no point in bringing this data into EBS.

2. Historical data do not have any reporting significance. All the reports related to this data has been taken, analysed, signed off and closed.

3. Historical data may have lot of errors. Especially if the historical data is taken from a non-ERP, non-integrated environment, there will be lot of errors. Bringing erroneous historical data may corrupt the current data

4. Historical data may consume huge amount of space in the EBS system and may impact the performance of the system.

The decision on historical data is similar to the one that you take when you move to a new house. You can either carry all the junk that you collected in the old house and fill the new house with old items or you can bring in only the important necessities to the new house. That is a decision that you take.

Invoice currency and payment currency different in AP

2011-10-28T20:50:00.000+05:30

In Oracle Apps, can we make payments in a different currency from Invoice currency?

One of the readers of this blog, Sreenu Vasulu, points out that there is a way to make AR receipts in a currency different from Invoice currency. He thinks that there should be a way to do that in AP as well.

This is a question that is regularly asked in implementations. As far as I know, there is no way to do this.

So the question of the day, Has anyone of you configured a solution in AP in Oracle where invoice currency is different from payment currency? How did you configure it?

Oracle OPM Solution for a Paper Industry

2011-10-13T08:28:00.000+05:30

I am currently in the middle of designing a solution for a paper industry. Paper industry comprises of a base product cut into different sizes, each size packed into different packing materials and shipped to customer. For example, one customer may order for a BP with a width 100 CM and packed using packing material 1. Another customer may order the same BP, with a width of 120 CM and packed using Packing material 2 and another customer may order the same BP, with a width of 200 CM and packed using packing material 3.
The planner will consolidate all these orders and produce 450 CM width of BP, cut it into different widths based on customer orders and pack them and ship them.
The planning and costing are at the BP level.
This is called Attribute based manufacturing.
This similar requirement exist for Food Processing Industry. For example, in the manufacture of flavored yogurt, the companies produce base flavorless yougurt and add flavours and pack them separately and ship it to customer. The customer will order Strawberry yogurt, the company will produce base yogurt and add flavors and pack and ship to customer.
Or in a bakery, a baker will produce one big cake of 10 Kg and cut them into cakes of 1 Kg, 2 Kg or 5 Kg and pack and sell them to the customers.
How can you handle this in an ERP application? It doesn't make any sense to create too many finished products and associated formulae. How do you optimize planning, costing and data entry minimization considerations?

ERP Journey - Risks faced by an SME

2011-09-06T09:43:00.039+05:30

So you are the Owner / CEO / CIO of an SME. You have heard a lot about the benefits of having an ERP in your organization. You have heard that it will bring in data integrity and efficiency to your operations. You can't wait to start..

Wait a sec, have you considered the following risks.

Small enterprises like yours face some typical risks while embarking on your ERP journey. The risk start at the time of evaluating the ERP and could, if not mitigated effectively, potentially go on for years after you have attained that holy grail of all implementations, vis. go live. Let us take a look at the top 10 risks that you may face in your ERP implementation journey.

1. Process Knowledge Risk: While your enthusiasm to go for ERP is appreciable, take a step back and see if you know your business processes. Do you know who are your top 10 customers, do you know how your balance sheet is generated, do you know the various statutory rules that apply to taxation for your industry, do you know the different types of items you purchase, do you know the conceptual / theoretical process of manufacturing key products, do you know how cost is calculated and tracked in your organization

Do you know.....

All right, you are the Owner / CEO / CIO, you are not supposed to know the details of these processes. But the question is does your Organization know these processes. Of course, there are people in your organization who know these processes. The key question is, is there anyone in your organization who know the integrated business processes in your organization? If the answer is yes, then, let me say this, you are very lucky. Get that person to quickly document the business process. If needed, get an expert to sit with him and get your processes documented. If you have documented your processes, you have crossed the first hurdle and mitigated the first risk. There is a good chance that your ERP implementation will be successful.

2. Pain Points Knowledge Risk: Do you know which are your top five, ten pain points? I have seen many organizations deciding to go for ERP implementations only because, either, their headquarters told them to do so, or, because their competitors have gone in for ERP. For them ERP is just another IT application like, say, MS Office, Excel or that tax application your internal auditor uses once a while. They do not have any clear expectations from ERP. They do not have a clear objective when going in for implementing ERP. If you do not know your pain areas, the chances are high that they will not be addressed during the implementation. Know your pain points, and have a clear measurable goal of incrementally reducing the pain points during and after the ERP is implemented.

3. Product Risk: So which product are you going to choose? Oracle? SAP? Any other? A friend of mine, who owns an SME company which implemented ERP, told me that while they were looking out for ERP, they did not have any awareness of any other ERP applications being available (other than SAP and Oracle) out there. This is a typical problem being faced by SMEs. Lack of information about product options means that you run the risk of choosing an application which may not be a fit for your organizations. SME industry being fragmented as it is, there is no single source of learnings related to ERP procurement, lessons learnt etc.

4. Product Versions Risk: So finally you have decided to go for a product. The next risk relates to the product version that you want to procure. As an SME, you will not be able to handle the implications of wrong choices. In percentage terms, a wrong choice could lead to significant monetary impact for your organization. There will be pressure from those in your organization to go for the latest version. After all that is the product direction and the vendor will be giving you good discounts to buy the latest version (they want 'early adopters'). Please remember that buying ERP is not like buying a consumer durable or a music system. The bigger / the latest may not be the better 'for you'. I think that it makes sense for you to go for a tried and tested version. After all, you are not a Fortune 500 company ( at least till now, who know what can happen once ERP is implemented)

5. Consultants Competence risk: As an SME, you may not be able to afford the TCSs and Infys of the world. This means that you have to go with smaller partner organizations. This decision entails its own risk. The smaller organizations may not be able to attract and retain talent. They may not have sufficient number of senior consultants with thorough implementation experience in SME sector. The consultants may not have enough business experience or will not be able to understand your business requirements. Or the consultants may leave midway through your project leaving you high and dry and unable to cope up with the time and cost overruns that entail as the implementation partner searches the market for a new consultant and then the new consultant takes his own time understanding your business process and the status of your implementation.

How do you handle such risk? One way is to modularize your implementation. Divide the project into optimum number of Stop Gates where you can take a 'Go - No Go' decision. Each Gate should have its own documented deliverables. The implementation methodology of most of the big application vendors automatically considers these 'Stop Gates'. If the methodology do not (consider these gates), insist that the implementation partner divide the project into suitable number of manageable milestones ('Stop Gates') with their own deliverables.

6. Internal Knowledge Risk: As an SME, chances are that there are only few resources in your organization possessing an Organization wide process knowledge. While these resources are valuable to you, remember that these resources will be much more valuable to the ERP ecosystem (competitors, Implementation Partners, Product Companies, Consulting Companies) once your implementation is completed. In case you have depended a lot on these resources to drive your implementation, without ensuring that the knowledge is transferred across the organization (building up internal capabilities), you run a serious risk of breakdown once the application / implementation goes live and the resources leave you.

How do you handle such risks? There are many ways to do that. First, as I mentioned before, is detailed documentation of the Business Process, the solution, the configuration, user manual, user training etc. Another way to handle it is to have multiple resources tagged to the main resource. As an SME you may not be able to afford that. Another way to handle this risk is through the use of an expert partner who can provide continuity for your implementation in difficult times.

7. Localization knowledge risk: As an SME your exposure and impact of this exposure to local taxation rules is much more significant than, say, a large enterprise. This means that solution of country / tax localization is a very important aspect of your implementation. The statutory / localization might have three types of implications / impacts in the order of increasing risk and complexity. They are one, reporting impact, two, transaction & reporting impact and three, transaction, accounting and reporting impact. The ERP application should support country localization. If not, the implementation partner should be able to suggest an acceptable solution for country localization. In this case it is very important for you (as the implementing organization) to be aware of the key requirements relating to your localization / statutory reporting. Ability of the application to meet these requirements should be a key criteria in deciding on the application to procure.

8. Period Closing Risk: Other than going live, the main milestone in any ERP implementation is the Closure of the first period. This activity entails many sub activities and is very significant to external reporting. At the beginning of the project itself you should be aware of how much time you are taking to close the period (both month and year). You should have a clear KPI to reduce this value post implementation. You could say something like 'Currently we close the month on the 10 of the next month and the year by the 20th of February every year. After ERP is implemented I want the month closing to come down to 5 days in the first year, 3 days in the second year and target 'one day closing' from third day onwards'. This will give you a powerful statement of direction for your ERP implementation.

9. Continuous Support / Maintenance Risk: Once you have gone live on ERP, you are bound to face issues, both major and minor, on an ongoing basis while using your ERP application. To resolve this you will require continuous support. No problem, many vendors offer you continuous support (at a fee, of course. In case your vendor do not have a dedicated team to support you post your go live, reject them during the procurement stage itself.
Assuming that your vendor has the necessary support available, the problem doesn't end there. Most of the technical support teams do not understand business, but understand only technology. So to interact with them, you have to be technology savvy. And that is a problem for an SME like you, who would rather invest your time on improving business, rather than learning technology.
How do you handle this? I wish there were easy answers. There are none. If you train some of your staff on technology, they are bound to quit sooner or later. To counter this attrition, you have to continuously have a pool of tech savvy resources. Training your resources on technology is not what you are there for.
You could outsource this aspect of operation. However, it is not very easy to find agencies / organizations that are into such activities. And they come at a price.

10. Lack of support knowledge risk.: In addition to knowledge of technology, you also need to be aware of your sources of support. There are vast sources of support for your problems available in the internet. There is the Vendor's portal, Vendors support portal, Vendor managed user forums, independent user forums, Specific business communities, generic technology communities (like IT Tool Box) and individual consultant blogs (like the one you are reading) available out there which can provide you with the knowledge and support that you require, often free of cost or at a nominal cost.
The problem is again the tech savviness of the organization. If the senior management and the key team are inquisitive, open to learning and open to embrasing technology, then you have a significant advantage in running an efficient and effective ERP application

A dedicated page for SMEs in India

2011-08-23T09:15:00.000+05:30

SMEs (Small and Medium Enterprises) in India face a set of special challenges when it comes to implementing ERP. Many of them want to Implement ERP and move to the next level. Most of them have sufficient budgets. However almost all of them find that the difficulties lie in details. For example, at the initial stage of the process when they need expert support, they do not find anyone. The ones available are quoting exorbitant costs. Experts are not available and those who claim to be experts neither have expertise in Business processes nor in technology.

I have been putting in a lot of thought into this aspect of SMEs. I also have a few friends who are die hard, old school manufacturers who want to go in for ERP but are hesitant about doing that. I want to help the SMEs in India become world class and I am convinced that the only way to go about it is through efficient use of technology.

So I am dedicating this page to provide support and guidance to SMEs in their quest to implementing ERP and getting all the benefits. Go ahead and show the world that SMEs in India have it in them to become world beaters.....

I will be there to support you as much as I can.

I have arrived as a consultant

2011-08-06T13:37:00.001+05:30

Have you felt this before? You are in a customer meeting. This is the initial stages of negotiations for a major deal. The customer says, I have A, B, C problems. And you go with, 'Have you tried this?', 'Why don't you do that' and like

All the time, you are concious of the fact that you are talking generic stuff. You are not sure of the details of what you are saying. You will definitely fumble if customer asks pointed questions asking you to go into detail of your solutions

So, the questioin is, How do you know you have arrived as a consultant?

Yesterday, I was in a casual call with a friend of mine. He wants to start a manufacturing company, and knowing that I was a consultant working with XYZ company in the area of manufacturing industry solutions, he asked me what are the problems that he could expect.

Knowing that he was talking about starting a Dairy manufacturing company I told hin the following.

"There are multiple challenges in Dairy Manufacturing. First one is the mismatch between Demand planning and Raw material planning. Milk products have a short shelf life and hence the demand planning has to be short term in nature. However when it comes to the supply of raw material, that is milk, you can't plan short term. You can't expect your cow to produce more milk this week than it produced last week because the demand of yougurt is expected to go up this week. The milk supplier needs a commitment of about 4-6 months for milk supply. So the demand - supply planning horizon mismatch is a key problem for the dairy industry.

Another issue is relating to raw material quality. The milk supplied by different vendors will be different in quality. So there is a challenge to have a standardized quality for your costing purposes but to maintain differentiated quality standards for payment to your suppliers. Obviously you cannot pay a supplier who supplied a bad quality the same amount as you pay to a supplier who paid good quality milk

Third challenge is to determine the cost of milk. Milk normally contains about 8-10 percent of different solids like Fat, Chemicals, Vitamins etc and the rest is water. How do you maintain consistent costing of milk considering the quantity of solids (Solid Costing) is a key problem in Dairy industry"

While I was talking to him I was never self consious. I knew that I had value to offer and I knew that the customer also knew of the value that I was bringing to the table. I was talking from my heart, fully confident that the customer is benifiting from what I was saying to him.

I had arrived as a consultant....

Solutions: Keep them core and simple

2011-08-06T13:12:00.002+05:30

Solution: A simple and logical option that completely resolves the core problem.

Scene at a barber shop (hair dressing saloon).

First customer enters.

Barber (BB): Sir, pl. come in. Pl. have your seat.

The FC (First customer) sits. Barber starts cutting the hair.

FC: So how is the business?

BB: Going good. Can't complain.

BB continues cutting...

FC: What are your main problems and issues.

BB thinks a bit.

BB: I am facing one problem. When I am cutting the hair of tall persons, I struggle to cut the hair on the top of the head properly. Many a times I get a lot of customer complaints.

FC: You have come to the right person. I am a consultant with XYZ corporation and I implement industry solutions. You have presented an interesting problem. Let me understand in detail. How tall are you?

BB: 5'2'' sir. I am very happy that a busy person like you have taken interest in my problem, sir.

FC: No problem. How tall is your tall customer?

BB: Anyone above 5'7'' is tall for me. My hands ache when I cut the hair. And I have to listen to the complaints.

FC: Why don't you lower the chair a bit?

BB: My chair height is fixed. An adjustable chair is expensive.

FC: My company has a solution for Hairstyling industry. We have named it 'Wash to Cash'. This is a complete solution for the hairstyling industry. It has modules that can help you track all the information that you will require. We have a 'Grey Hair' module that helps you manage your senior customers efficiently. We have a 'Blunt Razor' module. This helps you to find out which of your workers produce more cuts on the customers and help you identify if it is an attitude problem or a training issue. And you are lucky. We have added the 'Chair Slide' function in our latest release. This function automatically adjusts the height of the chair based on the height of the barber and the height of the customer. It is flexible and scalable.

BB: Sounds impressive. How much does it cost me?

FC: Today is your lucky day. We are currently initiating a discount offer on hairstyling industry solution. We are offering 3 user licenses for USD 10000. And you also get 3 user licenses free. Also, I will personally monitor the implementation of the solution.

BB: But sir, USD 10000 is my total turnover in my lifetime. I can't afford it.

FC: Fine. Let me see if I can position a better deal for you.

Hair Cut over, the First Customer (FC) leaves. Second Customer (SC) enters.

BB: Sir, welcome, please have your seat.

SC: Thank you. This place looks impressive. Do you have any problems?

BB: I was just talking to the gentleman who was here before you. I have one problem. I find it difficult to reach the top of the head of tall customers and cut their hair effectively. This leaves me with lots of unhappy customers.

SC: Why don't you buy a small wooden platform? This will increase your height.

BB: The problem with wooden platform is that I have to move it around when I am moving around customer's heads. This causes a lot of noice and customers do not like a lot of noise when their hair is getting cut. Also, the while moving the wooden platform, it can hit others leading to injuries.

SC: In that case, why don't you have paddings below your shoes? This will increase your height. Rubber paddings below the shoes do not cause noise and they do not have to be carried around. Also they help you cut the hairs of tall people effectively. So all your problems are addressed.

BB (Gushing): You have provided a simple and elegant solution to my core problem sir. I don't know why I did not think of this before.

Solution: A simple and logical option that completely resolves the core problem.

Implementing Lean - Accounts Receivables

2011-06-05T13:34:00.004+05:30

This is in continuation of my article on Implementing Lean.

There are many ways in which the consultant can help the company implement lean in an organization. Here are a few ideas.

1. Top 10 (20) debtors report: These are standard reports that any ERP application has in its library. However, many organizations do not use the standard reports and hence do not make use of this tremendous potential. A regular review of this report with corrective follow up actions can help in two ways. One obviously is that this helps in keeping debtors to a minimum and two, it helps in identifying the customers who are persistently high debtors.

2. Use of dunning letters: Most of the application provides the facility of sending dunning letters based on the required parameters and based on the nature of the relationship with the customer. Most organizations do not use the dunning letters and if at all they use the same, it is arbitrary in nature and not as per an appropriate schedule.

3. Use of ABC analysis (similar analysis) of customers: Many organizations do not have a standardized procedure for tracking high value customers. Especially at the beginning of the implementation, the consultant is told that all the customers are equal. This results in the consultant providing the same focus to a one time customer as he does to very high value customers. One example of this is that you wait to upload the complete data for all the customers (like statutory details, updated address etc) and the data load process is delayed since the organization do not have this information for a few low value customers. Remember, when it comes to ERP implementation, all customers are not alike....

4. Matching of Invoice and credit notes: Customer returns lead to your organization returning money to the customer in the form of a credit note. It makes sense while matching collections to match the invoice against the credit note and collect the net amount. Many a time, I have observed that this process is not happening and when your invoice goes to the customer, he will remind you of the pending credit note and ask you to resend the invoice after incorporating the credit note. The net effect is a delay in the recovery of debtor balances from the customer and a 'Fat' debtors.

5. Not netting off Customer and Supplier Balances: If your customer is also one of your suppliers, it helps to reduce both receivables and payables if you can net off the Customer Invoices (and credit notes) to Supplier Invoices (and debit notes). Many a times, these do not happen (because of different persons in charge of receivables and payables) leading to 'Fat' creditor and debtor figures.

6. Working in Silos despite the ERP: In any organization, there is a silo to take the order, another silo to approve it, another to pick the material, another to pack and dispatch it, another is to send the invoice and another to track the collections. Since ERP integrates these processes, it makes sense to use the power of ERP to have a single window view to the entire Sales operations. However, in the power and incentive dynamics of the organization, the silos exist despite the ERP. This leads to significant delay in the O2C Cycle.

7. Configuration Localization requirements: In many countries, including India, there are a lot of localization related configurations, transactions and reporting to be followed by the organizations related to the receivables processing. Most of the time, the users who are handling the localization are not brought into the implementation at the initial phases of the project and hence there is no focus on localization during the ERP implementation. The end result is that despite the ERP features of handling your localization requirements, all the localization tasks are done outside the ERP. This resulting in waste of ERP potential and further waste of resources in managing the localization outside the ERP system and final resource wastage in integrating ERP information to the localization information.

Effective use of Exception Reporting in ERP implementation

2011-04-27T11:17:00.003+05:30

In many of my ERP implementations, I am surprised to see the kind of customizations that I have been asked to incorporate to ensure that the 'User do not make any mistakes'. Simple ones include, 'Ensuring that the Employee code is numeric', 'The customer name is All Caps' etc. The complex ones include 'Ensuring that XYZ user enters the price correctly', 'The ABC user should enter only a particular type of Purchase Order' or that the 'DEF user raises sales order only for Channel customers'. I invariably end up customizing the application to meet the above requirements since standard applications have a limited capability in meeting some of the above requirements.

When I ask the organization why these customizations are required, after much hemming and hawing, the true reason comes out 'We do not trust our employees to be responsible. They will always make mistakes.....'

We are a theory X organization.

What is common to all the above requirements? As I see it, almost all of it tries to prevent user from entering an incorrect data. Most of the time the user enters incorrect data for two reasons. One, he doesn't know that he should enter the data in a particular format (Using All caps, Numbers etc). This is simply a process documentation/ training issue. Two, she has access to areas where they are not authorized to enter. This is an access control issue.

Or, finally there may be a fundamental problem in the organization that encourages employees to enter wrong data in the system.

One of the very powerful ways to identify the root issues is the use of exception reports. Once the control requirements are identified, these are very simple and logical and easy to design. There are two key benefits to use of exception reports. One, they help identify the root cause. If a user enters wrong data consistently, this may a simple case of giving her a training. And two, they ensure that some of the major issues come out in the open very early so that they can be identified and resolved. They also address the key issue with customizations in that they do not have any impact on future application upgrades.

Given the benefits of exception reporting, why do most organizations not go for that? There are many reasons. One, the implementation consultants themselves are not aware of the utility / benefits of exception reporting. Two, organizations are scared that employees will make mistakes and thereby their control systems will prove to be ineffective. The way to handle this is to have a combination of exception reports and control systems working together. And thirdly, generation of new exception report may be expensive to the organization. Finally, since exception reports are custom based reports, the customer is not able to see them in action at the requirement gathering stage and hence they decide on the customized controls.

I feel that it is the duty of the consultant to educate the customer on the benefits of exception reporting. It is my experience that many of the customers requirements are related to accurate data entry and minimizing errors and in this, the paradigm of exception reports can provide a lot of long term benefits to the organization.

What do you think? Have you 'sold' exception reporting to the customer in your implementations? What were the problems / issues that you faced? What was the result? Is it beneficial?

How can you implement Lean in an ERP implementation

2011-04-13T16:58:00.007+05:30

The concept of 'Lean' is the adaptation of Toyota Production System into western manufacturing processes. The lean involves elimination of any non-value adding activities to ensure that the customer pays for only value adding features in the product. The five principles identified in Lean are:

1. Specify what creates value from Customer's perspective

2. Identify all the steps along the process chain

3. Make those processes flow

4. Customer Pull rather than stock push

5. Continuous removal of wastes.

The principle of Lean identifies 7 wastes. These are:

1. Over Production

2. Over stocking of inventory

3. Waste of transportation

4. Processing wastes

5. Waste of idle time

6. Waste of operator time

7. Waste due to bad quality

While these identify the wastes associated with Manufacturing process, there are other wastes that can be identified in other processes. For example,

1. Waste related to Obsolete data: Most of the time, an ERP implementation leads to identification of a number of obsolete data. For example, in one of my implementations, we identified over 80000 cost components for an item which was adding only 0.5% of the total item costs. Once we removed these components, the costing program which used to take more than 36 hours to complete, finished in just 30 minutes !!!. Other similar examples include, obsolete stock, suppliers, Purchase Orders, Customer data etc. If we can ensure that we have a well designed system of alerts and reports and processes in place, the waste and time associated with tracking and searching the data can be significantly reduced.

2. Waste related to bad naming conventions: If we can design naming conventions properly, searching of data becomes easier and faster. For example, it is faster for the system to index and retrieve numerical data rather than alphabetical data.

3. Use of EDI: This can help reduce various data entry and remove the wastage of time associated with entry of invoices / credit notes etc.

4. Proper Scheduling of Batch Processes: By identifying dependencies and correctly and efficiently scheduling the batch processes, most of the tedious, regular activities can be moved to the time when system load is lesser.

5. Netting of invoices against credit memos before making supplier payments: Many a time we see that there are pending credit memos which can be netted off against the invoices. But the organization is not aware of their presence. Just by a simple alert, we could ensure that the credit memos are netted of thereby conserving valuable cash...

Note that I have not mentioned a single activity relating to the 7 wastes mentioned above which are all related to manufacturing process. The points that I have mentioned relate to the activities of a financial consultant.

When we talk of 'Lean' we think of manufacturing processes and tasks relating to manufacturing and inventory. However, any process improvement which can make the organization lean and agile will lead to process efficiencies and lowering of costs to the customer. And in this endeavour there are many a tasks that a financial consultant can implement.

I am identifying some of the points that can be implemented in each module to ensure 'Lean' in an ERP implementation. Many of the points being discussed are generic while the terminology being used is related to Oracle Apps.

1. Organizational Structure: All the ERP packages allows the configuration of the organizational structure. I have seen a few implementations where the Org. structure is either over configured (Too many Operating Units and Warehouses) or under configured. While too many Organizations will make data entry, configuration and Knowledge transfer a nightmare, too few of the organizations can lead to non-availability of effective analytical information.

2. General Ledger: The following configuration considerations in GL will help in bringing 'Lean'

a, The philosophy of 'Thin GL': In the pre-ERP days, the organizations are accustomed to collecting all the analytical information from the Books of accounts (GL). This includes mostly Customer Balances, Supplier Balances and Assets Details. However ERPs bring in a powerful tool in the form of Subledgers from where Organizations can get almost all the detailed informations from the corresponding Subledgers. This means that only a summary information need to flow to GL. This reduces the duplication of information (both in subledger and GL) leading to a 'Thin GL' and more lean accounts operations.

b. Too many or Too few Accouting Dimennsions: Associated to the above point is the design of Chart of Accounts. Since most of the ERPs offer wide flexibility in design of flexfields / dimensions, many organizations are prone to design more dimensions than necessary. Too many dimensions lead to the following wastes. 1. Duplication of information between subledger and GL, 2. Waste of the users time in data entry 3. Waste of users time in error identification and rectification 4. Waste of precious hardware space and 5. Complexity in GL reporting.

c. Too many GL Journal Entries: In the philosophy of 'Thin GL', almost all the operational accounting entries in GL should flow from the subledgers. Only the period end reversible adjustment journals should be entered in GL. However many organizations use ERP as a huge accounting package and enter far too many accounting transactions directly in GL. This leads to the following wastes. 1. Waste of Users time in entering GL transactions. 2. Waste of users time in manually identifying the linkage between these transactions and subledgers 3. Waste of ERP capability in the subledger modules 4. Waste associated with generating new reports and 5. Waste associated with manual reconciliation.

d. Too many customized reports: In GL , the report generating tool is very flexible in generating financial reports like P&L, Balance Sheet and CFS. However, many organizations prefer to use custom reports for reporting purposes. This leads to the following wastes 1. Waste of energy and time in designing and developing custom reports 2.Waste of energy and time in redesigning custom reports in case of application / database upgrades 3. Possibility of erroneous data in custom reports.

e. Non-utilization of ERP features: Primarily this includes non-utilization of all the useful features available in the ERP package. Traditionally an ERP implementation starts of with bare minimum features available in the ERP package. However, the full benefit of ERP package can be attanined only if the organization starts using more and more features available in ERP. The most basic and easy to adopt benefit is to use some of the standard reports available in each application. However, once the ERP operations stabilizes, the organization do not show the curiosity to review the available standard reports and incorporate more and more standard reports as a part of the decision making. A few simple examples are the 'Top 10 Customer report' or the 'Top 10 Supplier List', 'ABC Analysis reports' etc. Since most of these reports are parameterized, it will take some experimentation for the organization to identify the correct parameters set to be used to obtain the information relevant and appropriate to the organization.

f. Other wastes: One of the wastes relate to improper design. In this waste the key aspect relate to not incorporating realistic future considerations in the application design. For example, what is the expected life of this ERP application before business is expected to change leading to reconfiguration of this application. A practical example of this was in one of my implementations where the organization told me that they plan to use this ERP application for 15 (!) years and hence we increased the lengths of all the account dimentions to incorporate scalability. The result was a sub-optimal COA design. Another waste is related to non-consideration or minimal consideration of naming conventions in an ERP implementation. Very few consultants understand the importance of naming conventions. An inefficiently designed naming convention can lead to significant waste of time and costs and non-availability of valuable analytical information to the organization.

These are a few

What are the process improvements that an ERP consultant can implement to reduce waste and bring in 'Lean' in an organization? What have you implemented in your implementations? I am keen to know.

Share your experiences and let the other implementers benefit from your experience and expertise..

Also tell me what you think of this article. (Please use the 'Reactions' check box below. Would appreciate if you follow up the 'Bad' reaction with a comment detailing how it can be improved)

Inventory Valuation / Costing Challenges in an ERP implementation

2011-03-31T15:47:00.021+05:30

Introduction: One of the key challenges in an ERP implementation is the identification of the correct costing method to be used to get the maximum benefit to the organization. Most of the time, the selection of costing method is determined by the Consultant's familiarity with a particular costing methodology and not out of any specific organizational costing or inventory valuation challenges. In addition, most of the costing consultants are not aware of the accounting impact of their decisions. And finally, despite the fact that the costing process is an inherently 'averaging' activity, many consulting teams spent considerable amount of time debating on the 'most accurate' costing method. I start off this article by describing the various costing methodologies used. In this section, I will try to cover as many points as possible regarding the business benefits and disadvantages of each of the methodologies. In addition, costing being a performance evaluation criteria for different departments of the organization, I will also throw some light on the various incentives perspectives related to different methods. From there I move on to describe what I call as a 'Costing Continuum' with Specific costing at one end and standard costing at the other end. In the final section, I look at the various challenges faced by consultants with regards to costing. Costing has many impacts. It has an impact on the closing inventory valuation and by corollary, on the profit / loss of the organization. Since this impacts the P&L statement, this is considered by many organizations to be very sensitive configuration. Due to the incentive nature of Costing, many organizations build their bonus / incentive structure around costing. This has the impact of trying to load all the cost components on each and every unit of the finished product. This may lead to significant requirement of expertise on costing analysis and any attempt to change the costing method may be met with reluctance and even hostility by the end customer. It is very important for the consultant to navigate these challenges. Once she is able to do that, the rewards that accrue to the success of the project can be significant. My article attempts to help you succeed in your costing battle....

My Credentials: I think I am one of the few experts on implementing Costing solutions for manufacturing industries. I have implemented different costing solutions for manufacturing industry ranging from Specific costing on the one hand to Standard costing on the other with multiple methods like FIFO, PMAC etc thrown in in between.

Costing Methods

There are mainly 5 broad categorizations of Costing Methods. They are:

1. Specific costing

2. FIFO (First In, First Out)

3. Weighted moving average methods

4. LIFO (Last In, First Out)

5. Standard Costing.

As shown in the figure, the weighted moving average methods can further be broadly classified as:

a. Transaction Moving Average Method b. Period Moving Average Method (The period can be a day, a week, a month or even a year).

Some of the methods above are used only in case of discrete items (where the cost of each individual unit of the item can be clearly assigned, for example a piston), Period Moving average method is normally used if the cost of the individual unit of the item cannot be assigned (for example, milk).

Note that while we use the above methods to assign costs to the raw materials, these methods helps us to calculate the cost of the finished products. While the above difference is explainable in theory, the same difference brings in lots of challenges when we try to decide on a costing method. More of it later...

Let us examine each of these methods in a little bit of detail.

1. Specific costing: In this costing method, the cost of each individual unit of the item is identified and assigned on the basis of the actual / specific cost incurred in procuring the same. As you can easily see, the effort required in tracking separate cost for each individual unit of the item makes this a cumbersome method to handle. This type of costing is used mostly in case of low volume, high value purchases. An industry where this type of costing method is generally used is Jewellery manufacturing industry where the cost of each unit of finished product is different from another (based on the content of gold present in the item).

2. FIFO (First In, First Out): In this costing method, it is assumed that the individual units of items are consumed in the same sequence as they are purchased. For example, the first item procured is used up first, the second item purchased is consumed next and so on. This type of costing can be used in scenarios where the item do not lose its value over time with storage and there is a regular flow of items in the warehouse. Pl. note that, it is not necessary that the units are actually consumed in the same sequence of their arrival into the system, but for costing purposes it is assumed that the consumption pattern is the same as the receiving pattern.

As you can see, FIFO method is less accurate than Specific costing. Also pl. note that in times of inflation, FIFO method will show lower cost of consumption and will inflate the profit. Since the calculated profit has a taxation impact, the companies may be averse to show inflated profit in their books. This is an impact the consultant has to consider while recommending a costing decision.

3. Weighted Moving Average Methods: In weighted moving average methods, the cost of the item is calculated based on a formula which considers the quantity as weight. In this method, based on every transaction of the item, the cost of the item will get updated with the latest cost. The formula used is (Current Quantity X Current Cost + New Quantity X New Cost) / (Current Quantity + New Quantity). The weighted average cost method overcomes the drawback of FIFO method of not considering the inflation in Costing. Weighted average method reflects the market cost better than FIFO.

There are two methods of Averaging the cost. In the Transaction Moving Average Method, the cost of the units are updated based on each procurement receipt transaction. In Period Moving Average method, the procurements of the period are aggregated and the cost of the item reflects the cost of all the purchases of that item in the relevant period.

4. LIFO (Last In, First Out): LIFO method is not used in India, but is widely used in US and European Countries (I think). This method assumes that the items which were received last, are consumed first. (While formally this method is not used in Indian accounting system, this method is widely used in the Vegetable market in India. All the consumers want 'Fresh' stocks and the price of all the vegetables are updated with the latest cost. Classic LIFO). As can be seen, this method approaches closest to the current cost. It should also be mentioned that in times of deflation (or recession) this method inflates the profit and thereby the tax outflow. This is a double whammy for the organizations since in these periods the revenue also will be hit and organization ends up paying higher tax on lower revenue.

Not a very comfortable scenario......

5. Standard Costing: Can you guess what is the fundamental issue with almost all the methods we discussed above? The fundamental issue is that all the methods focus on correctly recording the cost information and hence there is very low emphasis on detailed analysis leading to cost efficiencies. In addition, all these methods calculate the costs post facto. This is where Standard Costing comes in.

In standard costing, the cost of the item is fixed for a given period. The value fixed is normally based on historical analysis of the costs. Since the costs are fixed for a particular period, the emphasis shifts to analysis of Variance. This means that whenever the actual cost shifts from the standard cost, the reasons for the variance are identified and corrective actions quickly taken. The corrective action could either be a process change or if the variance is secular in nature, the Standard cost itself is changed in the next period to reflect the secular change.

Standard costing has many an advantage. First of all, the cost information is used for analysis purposes, which is as it should be. To record the costs post facto is just a mechanical activity and do not benefit the organization at all. Also, Standard costing, based on its emphasis on analysis, helps to identify process or efficiency gaps and helps the organization to fill these gaps effectively leading to cost optimization. On the flip side, standard costing calls for some very detailed knowledge of the method and analytical tools on both the consultant and the organization. And finally, in case the cost of raw materials and resources are fluctuating around a mean, there is no much difference between Standard Costing and Actual Costing. In fact, I know of many organizations that use Actual Costing, but use the previous periods cost for analysis purposes (like in standard costing).

If the consultant knows the method and organization is ready for it, Standard costing can be a powerful tool for cost analysis and optimization, especially in challenging times.

Consultant's challenges in decision of costing method.

1. What is the impact of the decision on P&L : Every costing decision has two impacts. One is a balance sheet impact showing the value of the closing inventory. And the second is a P&L impact, showing the Cost of goods sold and thereby the operating profit. For the same revenue, if the closing inventory value increases, the operating profit of the company increases. When you are going to implement an ERP application, there will definitely be a change in the way the costs are presently calculated by the company. This in turn will lead to a P&L impact. An implementation consultant should be very clear as to how the change in the costing methodology will be impacting the P&L account. Pl. note that any impact on the P&L could have audit & taxation implication and implications for Shareholder value. So companies are very careful regarding making any changes to parameters that impact P&L.

2. What is the data entry impact?

Any packaged application works on the principle of GIGO (Garbage In, Garbage Out). For the consistent and correct calculation of costs, it is very important that correct and accurate data regarding material and resource usage is input into the system. While it sounds quite logical in practice, data entry can be very cumbersome, especially in a manufacturing industry. I have observed that in manufacturing industry, the entry of labour and overheads are the most difficult since these need to be manually entered and these tend to change over each production batch. I know of many companies who have decided not to enter the usage of labour into their process data and allocating the costs at the end of the period on the inventory (which is not a good idea).

Data entry can be of two types: One is the one-time data entry associated with the entry of opening balances of inventory. The other is the regular data entry, which the user on the ground have to enter on a daily basis. While the implementation team motivates themselves to enter data correctly as a part of go live, the entry of data accurately and regularly, over a long time can be challenging to the organization. One way to handle this is to identify data errors quickly through effective use of Exception reports. (more of it later in another post).

3. What is the costing incentive system in the organization?

Costing information is a very powerful tool. Like any other powerful tool, the effectiveness of the tool lies in the knowledge and purpose of the user of the tool. Costing information can be used both positively and negatively by the organizations. For example, the purchase price variance can be analysed in detail and the standard costs can be optimized to make it as close to the actual cost as possible. In this way the purchase price variance will decline over time. Also, this level of detailed analysis will provide the organization with a wealth of information regarding its procurement process.

However, many organizations use the purchase price variance to punish the purchasing manager. For example, if the supplier provides volume discount, a high level of PPV could show that the purchase manager did not make use of the volume discount facility. Or if the supplier provides early payment rebate, a high level of variance could show that the AP user did not pay promptly and this led to the firm losing the early payment rebate. In this case, the organization could use this information to punish the purchase manager or AP user respectively.

It goes without saying that in the long term, using the costing information for positive purposes can lead to lasting benefits for the organization.

4. What are the parameters in costing decision (Type of item, Volume of purchase, inflation..)

This is a difficult topic to address. For example, if the input prices are highly fluctuating, standard costing may not be of much use. If cost of the inputs vary from product to product (in precision industry or ETO industry), you are better off using the actual cost. If the purchase prices are stable, then use of standard costs can help you analyse the operational performance better than actual cost. If the number of item codes is very high, then standard costing may be very cumbersome. In case the number of new items being produced are very high, then again, identifying the standard costs may not be feasible.

Coming to inflation, as mentioned before, in an inflationary economy, FIFO will show high profit and hence will lead to high taxation.

In case of volume of purchase is high, then it is better to go with standard costing since you can track the operational performance better with this method.

Conclusion

As you can see, there are multiple parameters and implications to costing decision. In addition, an effectively implemented costing methodology can provide rich dividends to the organization in the form of valuable analytical data which can help improve operational effectiveness and increase profitability. It is the kind of intellectual challenge and the intellectual value add that you can give to an organization that makes working on 'Costing' very exciting.

Article on Solution Architecture

2011-03-12T00:25:00.006+05:30

About a month ago, I had conducted a poll where some of you had wanted to see an article on Solution Architecture for an ERP implementation. Finally the wait is over. Pl read the Article 'Solution Architecture for ERP Implementation'. As alwoys, comments are welcome and they keep me energized to write more articles.

Cleared PMP Exam

2011-02-24T11:28:00.002+05:30

I cleared Project Management Professional (PMP) exam conducted by Project Management Institute (PMI - www.pmi.org) yesterday. I am a certified Project Manager now.
A lot of relief....

Solution Architecture for ERP Implementation

2011-01-28T12:08:00.014+05:30

In the summer of 2007, I had the opportunity to work as the Solution Architect for a global program of a world leading organization with operations across 3 continents.

The organization had implemented / was in the process of implementing Oracle Applications solution across the entire organization. For each project they had a process of assigning a solution architect whose responsibility was to deliver a Solution Architecture Document.

This organization had a well defined Architecture department with over 400 architects. The team included specialists in the area of applications, information services, security, disaster recovery and operations. The team also included a set of Enterprise architects and a group of Solution architects.

What is the difference between Enterprise Architects and Solution Architects? While the enterprise architects fussed on the overall architecture of the company, Solution architects were specific to each project. Every project started off with a solution architect.

I was the solution architect for one such project.

The article below intend to highlight the solution architecture processes for an ERP implementation.

As per Zachman's model, the architecture of a company can be grouped under the following areas. Contextual, Conceptual, Logical, Physical and Detailed. In each of these areas, the architect need to ask the following 6 communication questions (What, where, when, why, who and How).

For solution architecting for my project I concentrated on the Conceptual, Logical and Physical part of the above 5 application areas.

In a typical ERP implementation, you will need to architect the following areas:

1. Overall architecture

2. Context

3. Application Architecture

4. Information Architecture

5. Infrastructure architecture

6. Security Architecture

7. Operations and control architecture.

In each of these areas, you start off with a conceptual architecture, which is then detailed into a logical architecture and finally further elaborated into physical architecture. While the conceptual architecture is at a high level, the architecture gets progressively elaborated as we move to the lower levels.

The detailed architecture is nothing but the configuration document which is essentially an output of the project team.

Should the Solution architect be an expert in each of the above areas?

No, solution architect should be an expert in one of the areas and should have a clear idea of the business. The role of the the SA is more of a co-ordinator who identifies the key resources / experts in each of the above areas and gets their inputs and consolidates the same into a single Solution Architecture document.

Overall Architecture

This is like an introduction to the Solution Architecture document and sets the stage for the details that follow. Overall architecture talks about the high level architecture for the solution. While it should not be very detailed (so as to break the mystery as it were) while it should also give sufficient high level details to spur the interest of the reader / user of the Solution Architecture document.

Context

Every project happens within a context. The context could be either a business context or a technological context. Sometimes the context could be the IT vision of the organization where it plans to implement the ERP solution as a prelude to implementation of other value added applications / solutions etc. Most of the time, the context is the high level, near / medium term IT roadmap of the organization. It is very important for the Solution architect to understand, document and validate the context under which the ERP implementation is being undertaken.

Application Architecture
Normally, when we talk of solution architecture, we tend to consider onlr the application architecture aspect of the ERP implementation. Almost like a primordial reflex, the solution architect will go around collecting information on various applications that integrate with the ERP system and then prepare a neat Visio diagram with many boxes and arrows showing the various applications and their integrations.

While primarily application architecture does that, it also does something more. Primarily the application architecture looks at:

1. The application landscape: In this the solution architect identifies the various applications that interacts directly and indirectly with the ERP system. For example, if application A provides inputs to Application B which in turn provides inputs to your ERP system, both applications A and B should be reflected in your application architecture.
2. Type of integration: There could be a number of questions that the solution architect should ask when he / she is looking at under the above heading. Key aspects to be considered include the data flow direction. Is it inbound (data flowing into the ERP system) or outbound (ERP system is providing information to another application)., Another aspect, is relating to scheduling. Is the integration going to be real time or batch. Yet another aspect relates to the integration type, will it be point to point, through a SOA based middleware, through FTP, or based on Workflows. My suggestion is that for small companies, it is very risky to go in for SOA based integrations since customer may not have the wherewithal to manage the same after go live (SOA consultants tend to be very expensive, and the whole SOA and BPEL tend to be very knowledge heavy).
The application architecture will have a close linkage with the Operations architecture mentioned above when it comes to Batch Program based integration and error detection and tracking.

Information Architecture

This closely corresponds to the application architecture. Information architecture deals with the type and volume of information that passes between various applications as well as between different modules in the ERP application. Information architecture deals with the following questions.

1. What is the type of information that flows between different applications.

2. What is the direction of information flow?

3. What is the volume of data flow (normal, peak)

4. What are the workflows and approvals that accompany these information flow?

5. What are the various documents that flow between the applications? Are they maintained in physical form or electronic form?

Infrastructure Architecture
Infrastructure architecture should consider the following. This is a very highly technical aspect of the Solution Architecting and Solution architect will do well to consider these aspects very early in the solution. Also this is an area which undergo a lot of changes and finally this is the area which, if not done correctly, can lead to lots of performance issues in the future as you near go live.

1. Hardware sizing: This is normally done by the hardware vendor. However it is very important for the Solution architect to have an idea of the logic used behind the hardware sizing.
2.No of nodes: This is a very important decision. In single node installation a single, parent server takes up all the performance load while in multi-node installation, multiple nodes share the performance loads. Multiple nodes help in load balancing and performance optimization. However, post go live management is better with single node installations. And finally, the installation complexity is higher with multi-node installations. Most of the time, this is a decision taken as a part of point 1 above.
3. Disaster recovery architecture: One aspect of Infrastructure architecture, esp. in big implementations is related to planning for disaster recovery. Here, questions abound. Some of the questions are: Process of disaster recovery: How will the disaster recovery be handled? If we are going for a separate server / data center, where it will be located? What s the lead time in moving from the main server to the disaster recovery server? Volume of data that need to be reentered in case of moving to the new server/ Load balance of disaster recovery server, for example, during normal hours, only a part of the server need to be dedicated to ERP and other applications can run on the same, but during the disaster period, many of the other applications will need to close to pave way for more load to be used by the ERP application. Another aspect is relating to the access to the application. How will the functional users be informed of the disaster and how they will start accessing the DR server? And finally, disaster recovery also should plan for data reentry by having buffer resources to enter the data backlog.
4. Moving back to the main server. Part of the disaster recovery architecture should also consider the process of closing the DR server and moving back to the main server once the core issue have been resolved. Since this is a planned activity, it is much less complex. Detailed procedure documentation and approval processes should be maintained during the entire process of moving to the DR server and then moving back again to the main server.
5, Application performance: In a 3 tier architecture, the information is entered in a thin client and this gets processed in multiple servers in the background. This could lead to a lot of wait time for the user between the time he / she enters the data and the system fetches back the process data. For most of these parameters, there are clear international benchmarks which the technical consultants should be aware of.

Security Architecture
Security Architecture is concerned with ensuring the security of the application and the data base. The security architecture for this solution is dependent on the overall security policy and network access policy of the organization.

Typically the security architecture should cover the following aspects.

1. Data Security: How will the database security will be maintained? How will the administrator maintain the passwords? How can the database password be protected? What is the policy for granting access to the database.

2. Application Security: How will the application be secured? How will the access to the application be controlled? How will the activity in the application be monitored? What kinds of Alerts are required? What are the possible error scenarios? How each scenario will be managed? What is the application security policy?

3. Access Control: What is the firewall policy of the organization? What is the network access policy? What is the application access policy? Will single sign-on be used? Will Active Directory be used to manage accesses? How the access to the network be managed from within the country? From abroad? What is the process of IP Management? Will static IP be used? Will dynamic IP be used? Will VPN be used? What is the process of accessing the network? Is logging in to the network mandatory for connecting to the application? Will separate accesses be used for database and application?

4. Password Policy: This policy applies to the management of passwords for the network, the database and the application. The key aspect here is the ownership hierarchy. Some of the questions that need to be addressed are: How are passwords going to be managed? Will we have tracking of passwords history? How frequently the passwords will be maintained?

5. Inactive accounts management: How will the inactive accounts be identified? Managed?

6. New account creation: What is the new account approval and creation policy? What is the procedure? What is the document tracking?

Operations and control architecture

This part of the solution architecture covers how the standard day-to-day operations on the application will be handled on an ongoing basis once the application goes live. The key questions that need answering are:

1. Back up strategy: What is the frequency of database backup? what is the frequency of application backup? Will it be a cold backup (Application and database are stopped before backup) or a hot backup? What is the tool used to keep the backup? Will the back up be on a CD, on tape or on another drive? How many days of data backups will be maintained? What time of the day the backup will be taken? What is the expected duration for taking the back up? For restoring the applications?

2. Process scheduling strategy: Every application will have a set of batch processes that need to be run during lean periods. So the questions are, What are the key processes to be scheduled? What are the interdependences and sequences? How will they be scheduled? What is the strategy in case of a process failure? What processes will be run during the weekdays? What processes will be run on weekends? On holidays? Who are the owners of the processes?

3. Performance tracking: The administrator should regularly track the performance of the system. This aspect of the architecture asks questions like, what are the key parameters to be tracked? How will the admin know that intervention is required? What are the expected issues and expected resolution plans?

Conclusion:
That's it. I have finally concluded the writeup on Solution Architecture. Most of the time initially, the Solution architect will develop the logical architecture and progress it will details of physical architecture as they emerge. In this way, the solution architecture document is an evolving document. While the solution architect should ideally be focusing on the end user (A house is there for people to live, nor for carpenters, plumbers and electricians to produce their deliverables), unfortunately, Solution architecture is considered as a technical activity most of the time and hence do not get the due review and importance from the project implementation team.

And that is the tragedy of the Solution Architect.....

My new 'Comments' Policy

2011-01-13T12:10:00.003+05:30

I got this idea from one of the blogs that I tracked.
From the month of January 2011, for each comment that I receive in my ERP Blog, I will donate Rupees One Hundred (Rs. 100) to 'Akshaya Patra', with a maximum of Rs. 1000 per month.
The 'Akshaya Patra' is the 'Bowl of Eternal Food' that Surya is supposed to have gifted to Yudhishtira in the indian epic Mahabharata. The bowl ensures that sufficient food is available to feed the Pandavas (Yudhishtira and his four brothers, their wives and their mother). I think the similar concept is that of 'Cornucopia' in Greek Mythology.
'Akshaya Patra' is a 'not for profit' foundation which is involved in providing mid day meals to the impoverished children in various schools all across India.
My comment policy means that for every comment you post, you are helping to feed and keep in school at least one impoverished child. Also, as an additional benefit, you are helping to improve the knowledge of the ERP implementation community across the globe.
Come on all of you, Donate your comments generously. Help keep children in school. Help strengthen the ERP Community. All it takes is a few minutes of your time.
Also please note that the person who contributes the maximum comments will get special mention in my blog every month. So ensure to let us have your name in the comments.
For details on Akshaya Patra Foundation, check out their website www.akshayapatra.org

Suggestion on a new article

2011-01-13T11:46:00.002+05:30

I have asked my viewers suggestion for a new article to be posted on my blog. I have two ideas at present and I can prioritise the ideas based on feedback from consultants.
Idea 1: Costing Concepts: Product costing remains as an albatross in the neck of any ERP manufacturing consultant. It is very important to the customer. However it is one of the most difficult topic to address. The costing issues start from the proposal phase. The first question to be addressed is What is the costing method that I should recommend to the customer? The decision on costing method will decide the manufacturing method to be recommended. If the costing method is to be period moving average (for example), then the manufacturing method has to be necessarily OPM (Oracle Process Manufacturing). On the other hand if the costing method is Transaction based averaging, then the manufacturing method will have to be discrete manufacturing.
The manufacturing processes and concepts associated with Process Manufacturing is distinctly different from those associated with Discrete manufacturing. So is the inventory valuation and the inventory accounting.
In the article on costing concepts I plan to cover the 'Costing Continuum' starting with Specific costing at one end and standard costing at the other end. I will cover the business advantages and disadvantages of each. I also want to stress the fundamental point that all forms of costing methods are necessarily 'Averaging' in nature and it is futile to spend too much time on identifying the 'Accurate costing method'.
The second idea relates to Solution Architecture. I had some experience as a solution architect for a global retail giant. My focus is on differentiating the Solution Architecture from Enterprise architecture (Don't worry, I won't make it complex) and then move on to the topic of Solution architecting for ERP implementations. Solution architecting consists of different architecting elements including Application architecture, Information architecture, security architecture, Operational architecture and so on. In my article I intend to give a brief overview of each of these with some basic examples. I also want to throw open my point that currently in most of the ERP implementations, while we talk of 'Solution architecting', we end up doing only the 'Application Architecture' part of the Solution architecture.
A good Solution Architecture will have many advantages like identifying the key risks early in the project, and identifying getting on board the key players in the Implementation team very early in the project.
I also have given an option for you to chose a topic that is close to your heart and which is disturbing you the most. In case you chose the 'Other' option, enter your choice as 'Comment' to this article.

Happy New Year....

2011-01-03T12:14:00.002+05:30

Wish All of you a very very happy and prosperous 2011. May your new year be filled with number of Successful ERP Implementation Experiences.....

Every job has to be done twice.....

2010-12-13T16:37:00.003+05:30

As per the book '7 Habits of highly effective people', you have to do every task twice.

Either you plan the task thoroughly, thereby first 'doing' the task in your mind, and go and act your plan, or go without planning, do the task, commit errors and redo the same.

This means,

Either you do once in your mind and once actually, or

Either do once actually, commit errors, and do the same task again correcting the errors.

Either way, you do it twice.

But the second approach has its pitfalls.

One, you might permenantly damage the thing that you are working on. For example, if you are filling a light bulb and it falls down and breaks, then you cannot do that task again. Only option is to spend dark night.

Two, You might temporarily damage it to the extent that it has become useless.

Three, You might face unanticipated pitfalls.

Somehow, going to do a task without proper planning is a norm rather than exception in ERP implementation scenario.

Consider my friend, X, going to collect requirements. He goes in without a plan. He has not prepared on the customer's business. He do not know, the key revenue and cost drivers of the business. He do not know who are the team that is going to attend the session from the customer side and he do not have any idea of the roles played by the people who have come to give him the requirements. He is not aware if the people that are giving the requirements are the same people who are going to support in his implementaion.

Totally unplanned.....

So what happened in the meeting?

The key information was not received, which was only identified when the team was configuring the solution. By the time the key resource who was to have given this information had moved to a new division and it took about two weeks, a lot of conflicts between the customer and the team and a loss of momentum in the project before the complete requirements were received.

This means.....

Mr.X went to collect requirements without a plan and had to do the same process again at a loss of money, time and motivation.

On the other hand, every time Mr.Y goes to collect the requirements he plans it perfectly. First of all he plans the physical infrastructure very carefully. He will know where the meeting will be held and he would ensure that all the basic requirements including projector and whiteboard, markers, duster all are ensured for the meeting. He will have a clear prior information on the participants in the meeting, and what are their roles and contributions in the meeting as well as in the ongoing project. He will know the internal power structure of the customer team attending the meeting. He will have a clear idea of the important and mandatory information that he will require to collect. If possible, he will prepare a questionnaire to collect all the mandatory information.

And he will communicate.....

He will constantly interact with his customer contact as to what are the important information that the customer thinks is important. He will ask key questions like What are the key concerns of the customer? What is the overall objective of the customer from this meeting? What are the individual objectives of each of the participants from the meeting? .....

Even before he speaks the first word in the formal session, he has already ran thru the sessions in his mind and he is ready with all the important questions and clarifications that make the requirement gathering session so succcessful. Every stakeholder including the customer, the customer Project Manager and his own team are all satisfied with the outcome of the meeting.

As you can see, both Mr.X and Mr.Y had to do the requirement gathering process twice. Only difference is that at the end of the session Mr.X had a frustrated stakeholder team while Mr. Y had an extremely satisfied stakeholder team.

Any guesses as to whose project will end up successfully?

My white paper being referred in Wiki

2010-08-13T01:30:00.002+05:30

My white paper on 'Data Migration Strategies in ERP' is being extensively referred to in the Wikipedia under Enterprise Resources Planning section.

Check out the reference 15 under 'Reference' Section here

It is very satisfying ....

ERP Implementation? Is it a functional or a technical process?

2010-08-08T22:04:00.015+05:30

This week's Poll relates to debates that I have had with a number of my fellow consultants. I am looking forward to a lively debate and participation in this poll.

The question is "Is ERP Implementation a Technical or a Functional Process?"

Is this an irrelevant question? An ERP implementation consists of both technical and functional activities. Many of the good consultants whom I have worked with are good at both functional and technical knowledge. Of course you can implement an ERP Project without any technical knowledge if you have a good business knowledge. In the same way, you can do a very good implementation with only technical knowledge if you have a good business user to support you.

Considering that an ERP implementation consists of both functional and technical activities, the question is very relevant in my opinion. In the initial phases of the project, the consultant is involved in collecting the requirements from the customer and in this phase of requirements collection, a knowledge of customer's business is very crucial and critical. While a knowledge of business is very important in this process, it is more important to have a very good common sense and ability to ask good questions and get correct clarification during this process. May be what is needed is to have good product knowledge and good common sense. May be you don't need to know the business at all.

So may be functional knowledge is highly overrated. It may not be that relevant.

On the other hand, a good functional knowledge can improve the quality of the implementation significantly. Functional knowledge helps the consultant thoroughly understand the explicit requirements of the customer and helps him to provide multiple businesss options to the customer for each of the requirements.

On the other hand, an ERP implementation involves a number of technical activities. For example, installation of the application, configuring the database, data extraction, data migration, data validation all these are technical activities. In addition, during the process of implementation, the team might come across many issues for which a good deal of technical knowledge is required. The most important activity in a project vis. extraction, migration and validation of data is a purely technical activity. In most of the ERP implementations, the errors made by a functional consultant are most of the time reversible, but the errors committed by a technical consultant are many a times only reversible at a great cost to the project in terms of money and time.

Then there is a group of consultants who call themselves 'Technofunctional consultants'. This is a term specific to consultants from India, who are predominantly technical consultants but who has gained a certain level of functional expertise working in multiple projects. These consultants want to move from technical stream to the functional stream and learn a little bit of functional knowledge. These consultants are 'Jack of All Trades but master of none' and though they call themselves 'Techno functional' most of the time their communication is heavily tilted in favour of technical vocabulary rather than functional vocab.

In general, I have observed that in the early stages of the project, functional knowledge is very important but at later stages in the project, it is the technical knowledge that plays a crucial role. The transition happens sometimes after CRP 2 when the configuration is completed and the processes are frozen...

So what do you think? Is ERP implementation mostly a functional process or mostly a technical activity? Or, is it, as the last option mentions 'Immaterial, since about 60% of ERP implementations fail anyway' (mind you, I don't belive that, personally)

The poll closed yesterday. As expected there was differences in opinion. Out of 5 Votes polled, 3 supported the option that ERP implementation is a 'mostly functional' activity while 2 supported that it is 'Mostly Technical' activities.

Thanks a lot for all the people who voted in this poll....

Delivering Healthy Projects: My view

2010-06-22T02:08:00.011+05:30

Everyone wants to deliver projects which are healthy and adds value to the customer. That is what each consultant wants when she goes to a customer location to implement a project.

The question is. how do you deliver a healthy project? Is there any secret?

I am giving below some of the tricks that I have learned over my short implementation experience.

During my 10 years experience of delivering full cycle ERP Implementations, I have learned that the trick to deliver a good project is to get the customer involved very early in the project.

In the initial part of any project, the load / effort incurred by the implementer is very high. Most of the time, the customer is not involved, is disinterested or is skeptical about the whole process. In addition, there will be situation where the customer user is simply aftraid of the purpose of ERP implementation and will not take any active interest.

As the project progresses, the customer team starts taking some of the load and over a period of time, the share of the load taken by customer increases and the share of the implementer's load reduces. A typical project will look like this.

In this case the load of the project shifts from the implementer to the customer somewhere in the middle of the Project. Usually this happens after CRP 2 Demo and before the CRP 3 demo. From the breakeven point onwards, the customer take the responsibility for the delivery of correct data, correcting the implementers process understanding and helping the implementation consultant. After the breakeven point, the implementation teams effort will gradually reduce as shown in the above figure or in some projects will remain at higher level for some time, while the implementation consultant is handholding the customer user.

However, there can be two major deviations to the above chart. In the first case, the breakeven point is reached much earlier in the cycle. This is very good for the project since, customer is taking the project load very early in the implementation cycle. Such projects invariably are highly successful with delivery of very high quality and the end result is a very satisfied customer. The chart relating to a successful project is shown below.

In the above chart, the load of implementation has shifted to the customer in the month 2 itself.

What are the factors which enable to transfer the load to the customer very early in the project?

First one is the knowledge of the consultant. Any ERP implementation is only as good as the weakest consultant in the team. To have a successful ERP, it is very important to choose the best consultants. They may be expensive, but the expense is worth the benefit that you will get from a timely and successful implementation. The consultant is very knowledgeable about the customer's business, understands customer's pains and also provides multiple options for any of the issues that the customer may be facing. The customer user on the other hand is characterised by high level of intelligence and willingness to take responsibility and load in the project.

And finally, the anatomy of a failed implementation. This is characterised by very delayed breakeven point. Normally, in such type of projects, the implementation consultants will be spending time by themselves, with hardly any interaction with the customer. The testing in such projects is characterised by creation of a lot of 'TESTCUST', 'TESTITEMS' etc, with the consultant hardly understanding the business of the customer. Normally, the implementation consultant will not be aware of the customer's business and will be a novice / ametuer in the use of the application. The chart below shows the lifecycle of such a project.

You can be sure that in such projects we will have finally a very disgruntled and unhappy customer.

That is it !! My views on how to implement a successful project. Hopefully you would have learned something from my experience. Pl. note that above reflect my views and is not based on any scientific concepts of Project Management.

The Three Faces (Phases) of an ERP Project Team

2010-06-22T00:07:00.004+05:30

In any ERP implementation, the implementation team passes thru three phases.
The first phase is what I would call the 'Acquaintance Phase'. This phase often occurs at the initial phase of the project where the implementation team do not have an awareness of the enormity or magnitude of the task at hand. In this phase there is a lot of getting to know each other, friendship and general amiability.
In the second phase, which I call the aggression phase, the team starts feeling the enormity of hte task at hand and their percieved lack of knowledge on how to handle many of the scenarios. In this phase, there will be a lot of data issues, lots of wrong process mapping and solutioning, lots of 'It is not my job's and 'I won't do it's. There will be blaming, lots of it. The implementation team will blame the customer, the customer will blame the implementer, everyone will blame the project manager.....
And finally, the dust settles, In the third phase, called the 'Mutual Respect' phase, every one in the team understands each others well. They team is aware of its strengths and weaknesses and everyone is focussed on a common goal. In this phase, normally there is no difference between the customer team and the consulting team, they work as one.
My argument is that almost all the projects go through these three different phases. However, the most useful phase for the project is the 'Aggression Phase' because that is the phase where the issues gets resolved and project moves forward.
Knowing that all the projects will go thru these phases, what is the lesson learned? The lesson is that the earlier the team reaches the 'Aggression Phase', the better it is for the project. As a project manager, it may be a good idea to generate aggression in the team at an earlier date. However it has to be clearly understood that the aggression should not become personal. The aggression in the project, if focussed on the issuses at hand will lead to a high quality project.
Much like the gold becomes purer on heating and beating.....

Knowing the customer: Is it important?

2010-06-19T06:04:00.007+05:30

I have a question.

When you are implementing a business solution for a customer, is it important to know the customer in detail? This is the subject of this weeks' poll.

I believe so. I think that if you are going to implement the business solution, it is very important to know the customer and their business in detail. The more you learn about the customer, the better the quality of the implementation will be. The knowledge about the customer will help you talk the language of the customer. For example, it always is better to talk about item '4411' rather than 'TEST1234', or for that matter customer 'Lester Martinez' rather than 'TESTCUST'.
It makes sense to put in the effort to know the key customers (may be the top 5) or the key suppliers, the key raw materials, the key products. It makes sense to know the customer's revenue, the plans, the key people in the organization... Etc.

My view is based on the idea that as an ERP consultant, you can add value to the organization and improve the quality of the implementation if you know the customer and their business.

However, my friend Ravi disagrees. According to him, it is better to leave the customer to know the business and you spending effort in learning about the product / application. He feels that time spent on learning the business can be better spent learning the application. That way, customer can focus on his requirements and you can focus on providing the best possible alternative solutions to his issue. He feels that it is better that the consultant spends time learning the application since a thorough learning of application will force you to clearly understand most of the business concepts. In Ravi's opinion, the best quality implementations
are where the knowledge of the customer is transferred to the best possible product options.

These are two different philosophies, I guess. My view says that ERP implementation is a business value enhancing process and hence the consultant should know the business thoroughly to provide the best business solutions. The underlying assumption is that the consultant knows more of business in general, and hence is in a position to provide value added advice to the customer (basically, Consultant knows it all..).

Ravi's view is that an ERP implementation is primarily a mechanical process. Once you have a solution designed, the rest of the processes like pilots, Unit Tests, Data Conversion etc are more of a mechanical process and hence it is better to learn how to 'Operate the Machinery' well rather than learning 'How the machinery works'.

What do you feel is the correct approach? Or is the whole question dependent on the type of solution being implemented? For example, if you are implementing a financial solution, it might be better to know the business, but if you are implementing a manufacturing solution, it might be better to ignore the business learning and purely focus on learning the product features?

Or is the whole question irrelevant?

OPM Implementation for a major Latin American Country

2010-04-27T03:22:00.003+05:30

Just implemented Oracle OPM (Oracle Process Manufacturing) solution for a leading latin american company. Went live in April, and today spoke to the Customer CIO. According to him, this was 'one of the best ERP implementations that he has been a part of '.

Felt really proud. I am the project manager of this project.

And in the process of implementing the solution, learnt a lot of spanish in the bargain.

The project was quite tough. Contrary to the perceived laid back approach, the latinos are a tough bunch of real professionals. I have never seen the customer demanding so much of perfection, except when working with Tamil Brahmin customers in India implementations....

Characteristics of a good consultant

2010-02-23T01:19:00.004+05:30

In my opinion, an ERP Consultant should have the following personality traits.

1. Listening Skills: The key trait that separates a good consultant from an average consultant is his / her listening skills. A good listener will be able to pinpoint the issues being raised by the customer and thereby provide the solution to the real problems of the customer. A good listener will most often use the 'Why' word a lot. A consultant who is not a good listener will most often end up in providing generic solution rather than providing specific solution to the issues faced by the customer. An average consultant can be heard using the phrase 'This is how the product works, you have to change the process'.

2. Closure skills: Most of the average consultants will provide almost complete solution, but fail to close the issue. This will lead to festering issues which will come to haunt you in the most critical times. Most of the time the closure can be achieved with a simple three line minutes of the meeting. However, I am surprised at the number of consultants who lack closure skills. Lack of closure skills is related to the third aspect of a good consultant, which is communication skills.

3. Communication Skills: While listening skills play a very important part in the initial stages of the project, this is only a part of the overall communications skills. There are three aspects to the communication skills. They are Listening Skills, Presentation Skills and Idea Selling skills. Presentation skills can be oral and written presentation. The communication skills should not be confused with ability to talk confidently. Communication skills relate to the ability to separate data from information, coming to very common sense root causes, and finding innovative solutions and finally convincing the customer about the strength of your solution. I have seen many very good consultants fail in this aspect.

4. People Skills: ERP implementation is nothing but a people management process. In the beginning of the project you have a skeptical and probably scared user from the customer side. It is the consultant's duty to make the user confident in the product and the solutioning so that at the end of the day he / she can add significant value to the implementation. Many a consultant fail in this aspect since they do not put the necessary time and effort to understand the customer user.

5. Business Knowledge: It is a no brainer that the implementation consultant should have the knowledge of business. What does this imply? It implies two aspects. One, knowledge of business, industry, statutory regulations etc and two, the detailed knowledge of the customer's business. Many a times the consultant goes thru a 10 months of implementation without having a clue on the customer's business or products. And that will lead to a bad implementation. I normally ask the following questions to understand the customers business. How many plants do you have, Which plant produces the most? What is the spread of production load between the plants? What product groups do you have? What is the most profitable product? Who is the most profitable customer? Who is the customer with most revenue for you? What are the raw materials? How do you do production planning? How do you manage inventory?. The idea is to understand the key pain areas of a business and try to address those pains in your implementation.

These are some of the skills that I think a good consultant should possess. What do you think?

Intake of Opening Balance

2009-11-05T15:40:00.004+05:30

There have been a number of questions being asked on the correct process of taking in Opening Balances in an ERP Implementation. As mentioned in some of my previous posts, the Opening balances fall into the following items.
1. Inventory Quantity
2 Inventory Cost
3. Supplier Balances
4. Customer Balances
5. GL Balances
All the items above have accounting implications. How do we go about taking in OB? The key challenge is that while all the above creates accounting transactions in the subledger, GL Balances also creates balances for the same accounts. This creates double balances in GL.
Different consultants follow different practices to handle the above scenario. The methodology falls into four types.
1. Do not tranfer the subledger accounting entries to GL for the Opening Balances
2. Transfer the subledger balances to GL, but map the same account to both sides of the subledger accounting entry.
3. Transfer the subledger balances to GL and then pass a reverse journal in GL
All these approaches have merits (except 1 perhaps), but I have found the following process to be very effective.
1. Create three separate OB intake acconts for the three modules. Map these accounts as balancing accounts for Creditors, Debtors and Inventory Accounts. The OB intake accounts should be Balance sheet accounts.
2 Take in Opening Balance and Post the accounting entries to GL. The GL will now look as follows.
Debtors A/c Dr
Creditors OB A/c Dr
Inv A/c Dr
Creditors A/c Cr
Debtors OB A/c Cr
Inv OB A/c Cr
3. Modify the configurations and replace the OB accounts with the correct expense accounts in the respective modules.
4. Enter the GL OB as GL transactions in the same period. You can use web adi to upload the transactions.When you upload the OB, ensure to replace the Creditors, Debtors and Inventory accounts with the corresponding OB Accounts. This means that while the OB accounts get one side of the accounting entry from the transactions entered in the respecitive modules , the other side of the accounting entry will come from GL transactions. So after posting the GL tranactions, these accounts will have a zero balance.Verify the same and end date these three accounts. (so that people do not enter transactions in these accounts by mistake)
5. The retained earnings account will automatically adjust to the correct value.
Of course, the above is a broad strategy for data conversion and there are many devils in the details as you do a deep dive into the process. Some of the challenges include, how to handle partially received POs which are yet to be paid, how to handle TDS etc.

What is the advantage of this method? By making sure that the OB Intake accounts have zero balances at the end of the process, it ensures complete integrity of the process. For example, any balance in the intake account will mean that the total balances in the subledger did not tally with the balances in the GL. This means that either subledger figures are wrong or GL figures are wrong - both of which could point to a loophole in the customer's current accounting system.

Analytical V/s Transactional Information

2009-07-23T08:10:00.004+05:30

Based on the type of decisions they help to make, information can be divided into two types. One, analytical information and two, transactional information. Analytical informations helps the organization to analyse the data. For example, a trend of purchase price of a raw material is an example of analytical information. Normally you do not take a transaction decision (like increasing the selling price) based on a single jump in the procurement price. Analytical information might ultimately end up generating a transaction decision (organization deciding to increase the selling price) but the main purpose of the analytical information is to help the organization analyse the data.
Transactional information on the other hand is an information which help to take a decision in the current transaction. For example, checking of quality samples is a transaction information. Based on a bad quality sample, the organization may decide to discard a production run altogether. The decisions based on transaction information is short term and immediate and alter the flow of the transaction. In jewellery industry for example, any change in the procurement price is reflected in a change in selling price. In this example, the procurement price of gold is a transaction information.
What is the relevance of the above to ERP implementation? Since analytical information is used to analyse the information, it need not impact the transactional flow. For example, if fluctuation in Procurement price is an analytical information, every single fluctuation need not be captured in the item cost. You can design a report that will provide the analytical data that you want from the above information.
Unfortunately this does not happen in real life implementations. A consultant who creates a GL flex field to capture the customer master is converting an analytical information into a transactional purpose. Another example could be that of a consultant increasing the number of balancing segment because client wanted 'Product wise trial balance'. Or that of a consultant designing an elaborate procedure to provide accurate 'average' price based on every little fluctuation in Procurement price.
Transaction information, as mentioned above, impacts decisions relating to the flow of transactions. Normally, the system should be designed to capture this type of information. Remember that the transaction information will most likely be used for analytical purposes, but the chance of analytical information being used for transaction purposes is very rare.
As a consultant, it is very important for you to differentiate the information requirement into the above categories. This will help you in creating an optimum solution.
If the information is analytical in nature, try to look for a reporting solution. If the information required is transaction in nature, you will need to capture this information in the application and configure the application to handle the flow of this information.

Sound Advice!!

2008-12-18T11:59:00.001+05:30

While creating a Chart of Account segments in Oracle, give the line numbers as 1,2,3,4.... etc. Sometimes the practice is to give the numbers as 10,20,30... etc which could cause problems when intgrating with certain applications.

Requirement gathering: The pain in a consultant's life

2008-09-02T05:19:00.006+05:30

"How do you prepare tea?"

"Well, we boil some water, put some sugar, add some milk, add some tea, put this powder and boil it all till it becomes tea".

"What is that powder?"

"We don't know."

"Then why are you adding it?"

"Because our mom used to add it?"

"Why did your mom add it?"

"We don't know."

In the world of requirement gathering, this is a scene one comes up so often. Here is an example.

"How do you you create a purchased order?",

"Well first we note down the details of the requirement, take a printout, get it approved and then enter the PO in the legacy system",

"Why do you get the PO approved and then enter in the system?"

"I think it is because....... well I don't know, I have always done it this way"

Or another,

"What are you expecting from the system?"

"We have many warehouses in the city. We need warehouse wise trial balance"

"Why do you need warehouse wise trial balance? do you track assets at each warehouse"

"No, but we are currently doing it this way and we want the system to provide that"

Requirement gathering can be one of the most frustrating part of an ERP Consultant's life. Especially if you are sitting with users who 'add the powder while making tea' without knowing why he / she is doing that way. They follow a process because they have been doing it that way since they started working. Can the system meet their requirements?

Unfortunately many consultants also end up providing whatever the user asks for without probing further without knowing the real reason for these requirements. Many a times it is due to the lack of business knowledge on the part of the consultants. Most of the ERP functional consultants join the IT industry immediately after graduation without having a feel of how the business funtions. Through practice they become very comfortable with the application and end up providing whatever the client asks for in a bid to please the customer. For instance, in the 'Trial Balance for warehouse' scenario mentioned above, one of the consultants came out with the idea of creating each warehouse as a 'company' segment value in Oracle. On deeper probing it was found that what the user wanted was 'warehouse wise profitability' which he had confused with 'trial balance'

He was making tea without knowing why he was adding the 'special powder'

PS: On deeper probing it was found that their mom used to add the special powder because they were living in a cold weather and the special powder had a way of invigorating the body.

Oracle Apps Financials: Some Interview questions

2008-08-13T20:26:00.004+05:30

I am giving below some of the interview questions relating to Oracle Financials that I have come across.
1. Oracle financials talk of Set of Books. However at the beginning of an implementation, when you talk of set of books to the CFO, he will most likely tell you that 'He has just an accounting book for the organization'. So he feels that he does not need 'Set of Books'. How can you reconcile the above two statements?
2. What is meant by 'Top Line' and 'Bottom Line'?
3. In P&L, what is 'Gross Profit', What is 'EBIDTA', What is 'cash profit'?
4. What is the concept of 'Bill in Advance' and 'Bill in arrears' in AR?
6. What is profitability? How do you map 'segment wise profitability' in Oracle?
7. Explain the accounting flow in P2P Cycle, O2C cycle etc
8. Foreign currency accounting: Explain conversion, revaluation, translation and remeasurement
9. How do you get the account description in FSG reports?
10. What is mass allocation?
11. Suppose I am paying rent regularly on the premises that I occupy. The amount and the account is the same for each month. What are the two ways in which I can map this requirement in Oracle so that the data entry is simplified. Which approach would you prefer? Why?
12. What are the different ways in which you can map intercompany transactions in apps? which one you prefer and why?
13. What is a ledger in R12? What are the four Cs of a ledger?
14. Is profit an 'Asset' or 'Liability'?
15. What is the difference between 'Periodic' accounting and 'Perpetual' accounting?
ney

Service Tax Flow in Oracle

2008-08-12T19:55:00.004+05:30

Introduction
Service Tax is a form of indirect tax imposed on specified services called "taxable services". Service tax cannot be levied on any service which is not included in the list of taxable services. Over the past few years, service tax been expanded to cover new services. The intention of the government is to gradually increase the list of taxable services until most services fall within the scope of service tax.In the Union Budget of India for the year 2006-2007, service tax has been increased from 10% to 12%. For the purpose of levying service tax, the value of any taxable service should be the gross amount charged by the service provider for the service rendered by him
Readers, pl. update this section by providing your comments
Accounting for Service Tax
Service tax follows 'cash basis' of accounting. The actual service tax impact occurs on the event of the closure of the document. For example, the service tax recovery occurs at the time of payment of AP invoice and service tax liability occurs at the time of entering receipts in AR. To integrate the cash basis accounting with the 'accrual basis' of accounting, minimum of four new accounts are setup in Oracle. They are the Service Tax Interim Recovery account, the Service Tax Interim Liability Account, Service Tax Receivable A/c and Service Tax Payable A/c.

Accounting flow in Service tax is simple and intutive.

On PO Receipt

Service Tax Interim Recovery A/c Dr
AP Accrual A/c Cr

On Payment of receipt matched invoice

Service Tax Receivable A/c Dr
Service Tax Interim Recovery A/c Cr

On entry of AR Invoice

Receivables A/c Dr
Service Tax Interim Liability A/c Cr

On applying the receipt against the invoice

Service Tax Interim Liability A/c Dr
Service Tax Payable A/c Cr.

On settlement, if there is a net service tax payable, an invoice is generated on the tax authority

Service Tax Payable A/c Dr
Supplier Liability A/c Cr

Other Features

1. You can net off service tax payable against Cenvat (RG / PLA) accounts
2. You can distribute service tax from one OU to multiple OUs

Since Service tax is an evolving legislation there will be a lot of new knowledge being generated. I want this site to be a one stop shop for Service Tax setting up in Oracle. Pl. be active with your comments so that all the users and viewers to this site can benefit.

Foreign Currency Transaction Concepts

2008-07-25T20:35:00.004+05:30

There are four concepts in foreign currency transactions. They are conversion, revaluation, translation and remeasurement.
1. Conversion.
Conversion takes place at the time of the transaction entry. Conversion converts the foreign currency value to the base currency at the days exchange rate. For example, if you have a payable liability of 100 USD and the exchange rate is 1 USD is 40 INR, the foreign currency payable is converted to the INR value of 4000.
2. Revaluation
This happens at the end of the period. The foreign currency account balances are revalued based on the period end exchange rate. Normally the impact goes into 'unrealized gains / losses' account. For example, if the exchange rate is 45 at the end of the period, the foreign currency payable is revalued to 4500 INR and the 'Unrealized Loss' in this case is Rs. 500. The accounting entry in the above case is:
Unrealized Loss Dr. 500
Liability Cr. 500
The above entry is either reversed at the beginning of the next period or carried forward. The actual realized gain / loss is booked at the time of closing the above transaction, by payment against the invoice in the above example.
3. Translation
Translation is used when the organization reports in a foreign currency which is different from its base currency. This process happens at the period end. In this case, the base currency trial balance is translated to the foreign currency trial balance. You can use different exchange rates to translate different account types. For example, you could use historical rates to translate owners equity and fixed assets, the period end rates to translate current assets and liabilities and period average rates to translate income statement accounts.
4. Remeasurement
This happens in situations where your base currency is an inflationary currency. In this case the parent will want to keep a close track of the transactions by remeasuring each and every transaction in the currency of parent company. For example if your base currency is Argentine Peso and the parent currency is USD, each and every transaction in Argentine Peso will be remeasured in USD in the day's exchange rate. This ensures a tight control by parent on the subsidiary's operations and provides the parent with a real time report of the subsidiary's financial performance. This helps effective intervention by the parent in case subsidiary's performance significantly deteriorates due to domestic inflation.

Checklist for initiating an offshore project

2008-06-04T08:26:00.003+05:30

Many of the Indian Companies are successfully deploying the offshore delivery model nowadays. Advances in technology and network efficiency has enabled them to connect to the customer network, work on the customer environment, deploy the solution and test the same. I am putting together here a few of the check points that we must consider while initiating an offshore delivery project.
1. Do we have network connectivity?
The normal tool used is VPN and it is normally customer's responsibility to establish the same. Sometimes customer's go for leased lines from ISPs.
2. Has the network connectivity been tested?
This need to be tested for access to the network, access to the development environment and in case of Oracle Apps opening of forms and finally for the connectivity continuity and speed. You may need to test this at different points in time in a week till you are absolutely comfortable.
3. Details of Customer Contact: Who is the customer contact? What is his role - for example is he only going to coordinate or is he an active participant in the project team.
4. Knowledge of English: Does the custmer have a project team which is conversant in English?
5. Database connectivity: Does this project require database connectivity? If yes has the connectivity details been received from the customer and has this been tested satisfactorily.
6. Database connectivity tool: Does the offshore project team have a database connectivity tool like 'Toad' and has the connectivity been tested using this tool.
7. Customer Support Identifier: Almost all the technology vendors have an online support portal for which the customer is given a restricted user identifier. For example, in case of Oracle, the portal is the Metalink and the number is called CSI. You need to receive the CSI number from the customer and the access to the same has to be enabled for the offshore project team so that they can raise support request in case they run into any product related issues during the project phase. You will need to ensure that you have tested the connectivity to the portal using the CSI number that the customer has provided.
8. Does the customer has any specific requirements? Has that been understood well by the project team? Has it been documented?
9. Prerequisites: Does the project have any prerequisites? Have they been identified clearly and action taken against each action item?

These are a few of the points that immediately come to mind. If you have any further points, do let me know so that we can together prepare an excellent checklist.

Preparing for Mark

2008-04-13T06:06:00.004+05:30

Mark was coming to our office.
Mark was the head of the IT arm of one of world's largest travel companies who were planning to implement Oracle Apps worldwide. Our organization was trying to get a slice of the pie.
The previous day we had an internal meeting.
"Mark want to meet the team here" informed our program manager, "we will have a team meeting with him tomorrow"
"What is the agenda?" one of us asked.
"We have to demonstrate our knowledge of the domain, the product, the technology and the implementation methodology (AIM)" replied the boss.
"When introducing ourselves we will mention our name, our Oracle Apps experience and our experience in using AIM" continued the boss.
All of us were ready for Mark.
The next day's team meeting went on expected lines. Each of us will get up, and like parrots, repeat 'Hi Mark, my name is ..........., I am a functional consultant with..... years of domain experience and ...... years in apps. I have worked on GL, AP......and have been a part of multiple implementations. I always ensure to follow AIM systematically and methodically to get the best results in our implementation....'
This went on and on. During all this Mark's face was unscrutable and our program manager's face was getting swollen with pride.
And finally it was Mark's turn.
"I see that all of you have done a lot of work using AIM" he observed.
All heads nodded in ascent.
"That is funny, because our organization do not believe in AIM. We feel that it is documentation intensive." He had a naughty smile which suggested that he knew about our team meeting the previous day.
Only sound that could be heard was that of our program manager picking up the broken pieces.

Setting up for Segment wise profitability in Oracle Apps

2008-04-11T08:56:00.003+05:30

The Accounting standards in various countries expects the organization earning revenue from multiple product segments to show the segment wise profitability information as a part of the Financial Reporting.

Here is how you can set up the same.

1. Set up an item category as 'Product Segment'.
2. In the GL Set of books, create a chart of account segment as 'Product Segment'. Give validation as table, and link it to the product segment field in the item category table.
3. Set up the cost of goods sold account in such a way that for each item, the corresponding 'Product Segment' value is debited during a shipment.
4. In the item attributes for invoicing, change the 'Product Segment' value in the 'Revenue Account' field to the corresponding value for each item.
5. In AR, set up the auto accounting to pick the 'Product Segment' Value from the 'Standard Lines' for Revenue Account.
6. Create an FSG report to capture Total Revenue, Total Cost and the Profitability for each Product Segment.

And you are done.....

Note:
In R12 there is a feature called 'Supporting Reference' which can provide you with the same information. This means that you need not create a chart of account segment called 'Product Segment' in your ledger. However you will need to create a custom report to provide you with the profitability since segment wise revenue information is available in AR and segment wise cost information is available in 'Cost Management' for Discrete inventory and 'OPM Financials' for OPM.

Why standard withholding tax do not meet the India Localization Requirements.

2008-04-05T10:21:00.001+05:30

I have had a number of queries as to why standard withholding tax feature in Oracle Apps do not handle India Localization Tax Deducted at Source (TDS) scenario.

The following are the reasons why standard withholding tax is not applicable for India Local Requirements.

1. In India, the concept of threshold limits is used in calculating the TDS. For example, I could say that the threshold limit on deducting TDS on a single invoice is Rs. 5000. This is called 'Single Invoice Threshold'. This means that for any invoice with value less than that amount, the TDS will not be applicable.
2. Along with the above, I could set up that TDS will be applicable only if the total value of all invoice exceeds a threshold limit, say 20000 (Cumulative Threshold). This remains alongwith the statement above.
3. Once the cumulative threshold is exceeded, all the invoices that were skipped earlier will come under the purview of TDS.

Simple illustrative example of above.

Let us say:

Rule 1: Threshold limit on single invoice: 5000, the TDS percentage: 5%
Rule 2.Cumulative Threshold Limit: 10000, TDS percentage 10%

1. Book invoice for Rs.1000. There is no TDS since both the above rules are not applicable.
2. Book another invoice of 5000. Rule 1 applies. System creats a TDS credit memo on the supplier for Rs.250 and a TDS invoice on tax authority for Rs. 250 thereby moving the liability from the vendor to the tax authoriry.
3. Book another invoice of Rs 3000. No TDS since the above rules do not apply.
4. Book another invoice of 1000. The cumulative threshold is reached. From now on, every invoice is charged TDS @10%. Hence, for this invoice, the system first creates a TDS credit memo of Rs. 100 on the vendor and a TDS invoice on tax authority for Rs. 100.
5. Along with the above, the system will create another TDS credit memo of Rs. 650 on the vendor and a TDS invoice of Rs. 650 on the tax authority. (Calculation: 10% of 10000 is 1000. TDS already paid Rs. 350 [250+100]. Balance 650).

The standard withholding tax do not handle such scenario.

Diagnostic Tools For Period/Year End Closure Activities;

2008-04-02T05:43:00.000+05:30

I saw this details while browsing 'Oracleappsblog'. Very useful.
Oracle Support has released a list of diagnostic tools to give you a very much needed heads-up, as to what might affect and hamper your year end closure. In order to get the latest version of tests available, you’ll need the following patches;
1. Oracle Diagnostics Framework 2.4 or later
2. Oracle Support Diagnostics 6.9 or later
Below is a list of the Diagnostics Oracle has recently released for each product. (Those with access to metalink you can refer to Document ID 402237.1 for details);
1. For Oracle Fixed Assets, there is the Oracle Assets Period Closing Activity Diagnostic Test. This analyzes the depreciation status of a given book over a given period of time.
2. For Oracle General Ledger there is Oracle General Ledger Period Closing Activity Diagnostic Test; This diagnostic test will assist with checking that a set of books period is ready to close in General Ledger.
3. For Oracle Payables, there is the Oracle Payables Period Closing Activity Test. This diagnostic test will help in determining if a period can be closed and if not, why it cannot be closed. I can imagine this test is of immense value. I was on the AP period end closure team and we mainly relied on running reports to determine which periods are open, which transactions are outstanding/unaccounted and why. Some of the reports we used were the AP Trial Balance, the Unaccounted Transactions Report, the AP Accounting Health Check diagnostic, and a several others. This was quite a tedious and time consuming process; considering that our client more often than not operates multiple open periods. I’ll be sure to call upon this diagnostic tool in next years FYE closure.
4. For Oracle Receivables we’ve got Oracle Receivables Period Closing Activity Test. This tracks down and reports unposted items for a given period in the primary book and its associated reporting books if any.
5. Oracle Cost Management has the Oracle Cost Management Period Closing Activity Test which will verify pre-requisites for a successful inventory period close related to costing.
6. Oracle Inventory has the Oracle Inventory Period Closing Activity Test is available. This diagnostic test checks all mandatory and recommended requirements necessary to allow a successful Inventory period close.
Oracle also has availed Closing Period Test Sets. For the Financials Suit of Products, it’s given the IZU_IZU_FIN_CLOSING test set, which contains diagnostic tests verifying readiness of a period to be closed and identifying potential issues preventing successful closure of the period. The tests are executed for Assets, General Ledger, Payables, and Receivables.
For the SCM and Distribution suit of applications, it’s given the IZU_IZU_DIST_CLOSING test set. This test set contains diagnostic tests verifying readiness of a period to be closed and identifying potential issues preventing successful closure of the period. The tests are executed for Inventory.
By and large, for any one who is working in a support environment, module diagnostic tools are very imperative in investigating product flaws and faults, particularly those that pertain to the product back-end, and ensuring timely resolution of issues.

Period Closing Process in Financials in Oracle Apps 11i

2008-03-20T22:10:00.000+05:30

View Article in IT Tool Box
Introduction
Period End Processing - Summary
1. A summary of the period-end procedures for each of the Financials applications

2. An indication of the order in which the steps should be undertaken.
Steps
Payables
1. Complete All Transactions for the Period Being Closed
2. Run the Payables AutoApproval Process for All Invoices / Invoice Batches
3. Review & Resolve Amounts to Post to the General Ledger
4. Reconcile Payments to Bank Statement Activity for the Period
5. Transfer All Approved Invoices Payments, Reconciled Payments to the General Ledger
6. Review the Payables to General Ledger Posting Process After Completion
7. Submit the Unaccounted Transactions Sweep Program
8. Close the Current Oracle Payables Period
9. Accrue Uninvoiced Receipts
10. Reconcile Oracle Payables Activity for the Period
11. Run Mass Additions Transfer to Oracle Assets
12. Open the Next Payables Period
13. Run Reports for Tax Reporting Purposes (Optional)
14. Run the Key Indicators Report (Optional)
15. Purge Transactions (Optional)
Purchasing
1. Complete All Transactions for the Period Being Closed
2. Review the Current and Future Commitments (Optional)
3. Review the Outstanding and Overdue Purchase Orders (Optional)
4. Follow up Receipts-Check with Suppliers
5. Identify and Review Un-invoiced Receipts (Period End Accruals)
6. Follow Up Outstanding Invoices
7. Complete the Oracle Payables- Period End Process
8. Run Receipt Accruals - Period End Process
9. Reconcile Accounts - Perpetual Accruals
10. Perform Year End Encumbrance Processing. (Optional)
11. Close the Current Purchasing Period.
12. Open the Next Purchasing Period.
13. Run Standard Period End Reports (Optional)
Inventory/WIP
1. Complete All Transactions for the Period Being Closed.
2. Check Inventory and Work In Process Transaction Interfaces.
3. Check Oracle Order Management Transaction Process.
4. Review Inventory Transactions.
5. Balance the Perpetual Inventory.
6. Validate Work In Process Inventory.
7. Transfer Summary or Detail Transactions
Close the Current Oracle Payables and Oracle Purchasing Periods 8.
9. Close the Current Inventory Period
10. Open the Next Inventory Period
11. Run Standard Period End Reports (Optional)
Order Management
1. Complete All Transactions for the Period Being Closed
2. Ensure all Interfaces are Completed for the Period (Optional)
3. Review Open Orders and Check the Workflow Status
4. Review Held Orders
5. Review Discounts
6. Review Backorders
7. Review and Correct Order Exceptions
8. Reconcile to Inventory
9. Reconcile to Receivables (Optional)
10. Run Standard Period End Reports
Receivables
1. Complete All Transactions for the Period Being Closed
2. Reconcile Transaction Activity for the Period
3. Reconcile Outstanding Customer Balances
4. Review the Unapplied Receipts Register
5. Reconcile receipts.
6. Reconcile Receipts to Bank Statement Activity for the Period
7. Post to the General Ledger
8. Reconcile the General Ledger Transfer Process
9. Reconcile the Journal Import Process
10. Print Invoices
11. Print Statements (Optional)
12. Print Dunning (Reminder) Letters (Optional)
13. Close the Current Oracle Receivables Period
14. Reconcile Posted Journal Entries
15. Review Unposted Items Report
16. Open the Next Oracle Receivables Period
17. Run Reports for Tax Reporting Purposes (Optional)
18. Run Archive and Purge programs (Optional)
Assets
1. Complete All Transactions for the Period Being Closed
2. Assign All Assets to Distribution Lines
3. Run Calculate Gains and Losses (Optional)
4. Run Depreciation
5. Create Journal Entries
6. Rollback Depreciation and/or Rollback Journal Entries (Optional)
7. Create Deferred Depreciation Journal Entries (Optional)
8. Depreciation Projections(Optional)
9. Review and Post Journal Entries
10. Reconcile Oracle Assets to Oracle General Ledger Using Reports.
11. Run Responsibility Reports (Optional)
12. Archive and Purge Transactions (Optional)
Projects
1. Change the Current Oracle Projects Period Status from Open to Pending Close
2. Open the Next Oracle Projects Period
3. Complete All Maintenance Activities
4. Run Maintenance Processes
5. Complete All Transaction Entry for the Period Being Closed
6. Run the Final Cost Distribution Processes
7. Interface Transactions to Other Applications (AP, GL, FA)
8. Generate Draft Revenue for All Projects
9. Generate Invoices
10. Run Final Project Costing and Revenue Management Reports
11. Transfer Invoices to Oracle Receivables
12. Interface Revenue to General ledger (Project Billing Only)
13. Run Period Close Exception and Tieback Reports
14. Change the Current Period Oracle Projects Status from Pending Close to Closed
15. Advance the PA Reporting Period (Optional)
16. Update Project Summary Amounts
17. Restore Access to User Maintenance Activities
18. Permanently Close the Oracle Projects Period (Optional)
19. Reconcile Cost Distribution Lines with General Ledger (Optional)
Cash Managment
1. Load Bank Statements
2. Reconcile Bank Statements
3. Create Miscellaneous Transactions
4. Review AutoReconciliation Execution Report
5. Resolve Exceptions on the AutoReceonciliation Execution Report
6. Run Bank Statement Detail Report
7. Run Transactions Available for Reconcilaition Report
8. Resolve Un-reconciled Statement Lines
9. Run the GL Reconciliation Report
10. Run the Account Analysis Report for the General Ledger Cash Account
11. Review the Account Analysis Report
12. Correct any Invalid Entries to the General Ledger Cash Account (Optional)
13. Perform the Bank Reconciliation
General Ledger
1. Ensure the Next Accounting Period Status is Set to Future Entry
2. Complete Oracle Sub-ledger Interfaces to Oracle General Ledger
3. Upload Journals from ADI (Applications Desktop Integrator) to Oracle General Ledger
4. Complete Non-Oracle Sub-ledger Interfaces to Oracle General Ledger (Optional)
5. Generate Reversal Journals (Optional)
6. Generate Recurring Journals (Optional)
7. Generate Mass Allocation Journals (Optional)
8. Review and Verify Journal Details of Unposted Journal Entries
9. Post All Journal Batches
10. Run General Ledger Trial Balances and Preliminary Financial Statement Generator Reports (FSGs)
11. Revalue Balances (Optional)
12. Translate Balances (Optional)
13. Consolidate Sets of Books (Optional)
14. Review and Correct Balances (Perform Reconciliations)
15. Enter Adjustments and / or Accruals and Post
16. Perform Final Adjustments
17. Close the Current Oracle Gneral Ledger Period
18. Open the Next Oracle General Ledger Period
19. Run Financial Reports for the Closed Period
20. Run Reports for Tax Reporting Purposes (Optional)
21. Perform Encumbrance Year End Procedures (Optional)

Note: This list talks at various points about the 'Standard Reports'. If you can name the standard period closing reports in various modules, that can add value to this list. Do contribute to make this list comprehensive.

TDS Flow in Accounts Payable - Oracle Apps India Localization

2008-03-14T22:25:00.005+05:30

Review this article before you read this.

Introduction
Organizations are expected to withhold a percentage of the payments that they make to their suppliers and remit the amount thus collected with the tax authorities at the end of every specified period. This process is known as Withholding Tax or Tax Deducted at source.
The suppliers in turn receive a certificate to the extent of the amounts thus remitted and they will file the same with the Tax Authorities as a part of their Income tax declaration.
While withholding tax calculation in majority of countries is effective at the time of making payments to the suppliers, in India the Tax Deducted at Source (TDS) is effective at the time of accepting the supplier invoice itself. This makes the tax calculation, managemet and tracking much more complicated especially in an ERP Scenario.
This document tries to discuss an overarching scenario, where the TDS is calculated at the time of entering a supplier advance (Prepayment) and netting the same off against the invoices entered in the Oracle Applications Accounts Payable module.
1.When prepayment invoice is generated in AP.
In Oracle Apps, you enter a Supplier Prepayment as a Supplier Invoice of type 'Prepayment'. In this example, we are entering a prepayment of Rs.55000. Accounting entry generated is as follows.

Prepaid Expenses Dr 55000
Liability Cr 55000

2. System Creates TDS Credit Memo on supplier (Assuming 10% is the rate)
At the time of validating the above invoice, the system creates two additional documents. One, it creates a credit memo on the supplier (discussed in this step) and two, it creates a TDS invoice on the Tax Authority, thus moving the Tax from the supplier to the Tax Authority (discussed in step 3 below). For this purpose, Tax Authority has to be created as a Supplier in the ERP system
In this example, TDS rate of 10% is assumed.

Liability Dr 5500
TDS Control A/c Cr 5500

The rate gets picked up from the tax master where we have defined the tax as type 'Tax Deducted at Source'.

3. System Creates TDS Invoice on IT Authority (TDS Supplier)
This is already discussed above.

TDS Control A/c Dr 5500
Liability Cr 5500

4. Making the payment to the supplier on the prepayment invoice created above.
You will net off both the prepayment invoice (step 1) and the credit memo (step 2) when making the payment to the supplier.

Liability Dr 49500
Cash/Cash Clearing Cr 49500

5. Making the payment to the tax authority on the TDS Invoice

Liability Dr 5500
Cash/Cash Clearing Cr 5500

6.Enter Standard Invoice on Supplier (Raising invoice of 40000)
Here we are entering a standard invoice on the supplier and netting it off with the prepayment created above. The invoice amount is Rs. 40000. At the time of validating this invoice, the system will create TDS Credit Memo and TDS Invoice as discussed previously (Steps 2 and 3).
Accounting entry for the invoice.

Expense Dr 40000
Liability Cr 40000

7.TDS Credit Memo on the above invoice

Liability Dr 4000
TDS Control A/c Cr 4000

8.TDS invoice on IT Authority

TDS Control A/c Dr 4000
Liability Cr 4000

9.Attaching Prepayment created above to the current invoice.

Liability Dr 40000
Prepaid Expenses Cr 40000

10.TDS Return Invoice on supplier to reverse the original TDS Credit memo on the Prepayment.
This is a bit complicated to explain. If you make payment to the tax authority on this TDS invoice (created in Step 8), you would have made a total payment of 5500+4000 to the tax authority. This is wrong. Actually you don't have to pay anything on this invoice since you have already paid the TDS on the prepayment. To reverse the TDS Credit memo and the TDS Invoice created above (in step 7 and 8), the system creates a Reversal Invoice on the supplier and a Credit memo on the tax authority to the extent of Rs.4000

TDS Control A/c Dr 4000
Liability Cr 4000

11.TDS Return Credit Memo on IT Authority to reverse the Original TDS Invoice on the Prepayment

Liability Dr 4000
TDS Control A/c Cr 4000

Note that TDS Control A/c is an intermediate account which gets netted off at the end of a TDS Credit Memo and a TDS Invoice. This account is set up when you set up the tax master.

Please update your queries or comments so that I can respond to the same.

What did you think of this document? Pl feel free to comment. That is the only way to improve upon this.

Importance of soft skills for an ERP implementer

2008-02-20T11:11:00.000+05:30

The title sounds like a cliche. 'Importance of soft skills'?. Of course an ERP implementation consultant needs soft skills like communication skills, listening skills etc. Isn't it why we give them training on soft skills?
I also went thru these training. But read on.....
On the first day of my first ERP implementation, (in the year 2001, when risk management in ERP implementation was not much in vogue) we were having a meeting with the MD of the organization. This was a small organization in the manufacturing sector. On being asked his expectation from the implementation, he replied 'I want to see a trial balance from the system that matches my current trial balance from the legacy system'.
Simple expectation?...
While loading the data into the ERP system, I observed numerous data errors in the legacy data.There were duplicate invoice entered in one month, which were not correctly reversed / deleted in the same month, or reversed in the current month, again reentered in the next month against a different supplier, payments updated but cash not updated, multiple suppliers....
Royal mess it was...
After discussing with the finance manager, we decided that we will rectify the errors and get the correct data into the ERP system. We did not want wrong / rubbish data in the ERP system. The finance manager gave us the go ahead and we went ahead...
Of course the TB did not tally...
MD rejected the implementation outright. He reminded us of his expectation on day one. It turned out that the finance manager did not have much of a say in the organization's proceedings and MD was taking all decisions. He was worried when the internal auditor told him that the ERP implementation was a failure. The internal auditor was covering his tracks for not identifying the data mistakes.
Of course, we had to reverse all the data that we entered in ERP and enter the wrong data to match the TB......
If only I had listened properly....

Do you have any such experiences which demonstrates the importance of 'Soft Skills'? Do share with us

Comments from a frustrated tech. developer

2008-01-23T21:28:00.000+05:30

"Oracle is like a four legged animal. Most of the important work is done through the backend." Comments from a technical developer frustrated with his inability to find the links between two different tables in Oracle.

Do you know of similar opinions? Pl. share it here.

Problem in Stopping the Instance!!

2008-01-14T08:33:00.000+05:30

Have you experienced this before? Something that I am not able to understand...

Every time you go for a project in an organization where ERP is already implemented, one of the key issues raised by management is this.

"We can't stop ERP for a long time. We have production schedules and shipping schedules to be adhered to. If we stop ERP now, this will suffer"

I tell them that we are not asking the organization to stop the physical activities. They can continue with production, shipping etc. What I am asking is to delay the data entry in the system by a few hours...

Most of the time, the realization dawns and the organization is able to release the system for our activities...

Have you ever faced this issue? How do you tackle this? Is my logic right or is there any basic points that I am missing out here? Any input is welcome...

Steps in ISO Cycle

2008-01-06T06:06:00.000+05:30

Set Up:
1. Item to be set up as 'Internal Ordered' and 'Internal Orders Enabled' .
2. Shipping network to be set up between the sending Org and the Receiving Org. (N) Inventory --> Setup --> Organizations --> Shipping Networks

Process:
1. Create an Internal Requisition in the PO Module
2. Run the 'Create Internal Orders' Process in the PO Module. If everything is set up correctly, this will create an internal order.
3. Run the 'Order Import' Process in Order Management Module. Select 'Source' as 'Internal' and 'Reference' as the internal requisition created in step 1. This will create a new order in OM
4. Ship the item in Order Management, when shipping the 'Interface Trip Stop' Process will run followed by 'Receiving Transaction Processor'.
5. Create a receipt in the PO Module. Select the 'Requisition Number' as the 'Internal Requisition' created in Step 1.

This completes the ISO Cycle. The accounting entries generated are as follows.

Accounting:
1. On shipping the item:
Inventory A/c Cr
Inter Org Transfer A/c Dr

2. On receipt:
Inventory A/c Dr
Inter Org Receivable A/c Dr
Inter Org Transfer A/c Cr
Inter Org Payables A/c Cr

Please let me know if you faced any problem while following these steps. Do share with me so that I can update the documentation.

Topics for poll...

2007-12-22T07:30:00.001+05:30

I want to liven up the poll in my blog.

Can you suggest some topics that I can use? Some issues / problems or opinions.

I want the community to answer your questions.....

Using R12? Don't forget.....

2007-12-22T07:17:00.000+05:30

1. To run the process 'Validate Application Accounting Definition' from 'Payables' or 'Purchasing' responsibility for your ledger. This is to be done if you are using 'Subledger Accounting'

2. If you are using OPM, you need to create your own SLAM (Subledger Accounting Method) and link it to your ledger in GL. The seeded 'Standard Accrual' SLAM will not work in this case. This means that you have to create your own ADRs (Account Derivation Rules) for application 'Process Manufacturing Financials', create new JLDs (Journal Line Definitions) and link the ADR created above to that, create a new AAD (Application Accounting Definition) and link the JLDs created above and finally create a new SLAM by linking the above AAD. Remember, you can copy the 'Standard Accrual' SLAM and end date / delete the seeded AAD for 'Process Manufacturing Financials' and replace it with your AAD created above. The other AADs need not be touched.

3. Again, if you are using OPM Finacials, don't forget to run the 'OPM Accounting Preprocessor' before creating accounting.

4. For each module, you need to run the 'Create Accounting' process from that module. This means that for creating accounting entries in OPM, you need to run the process from 'OPM Financials' responsibility

R12 Procure to Pay Cycle Testing

2007-12-11T12:24:00.001+05:30

I have just completed full cycle testing of Procure to Pay Cycle in R12 vision instance.

What does this mean?

1. Created a legal entity
2. Crea stepted a ledger. Linked the SL Accounting method 'Standard Accrual' to the ledger
3. Linked both
4. Created OU, IO and linked the same.
5. Created item, supplier etc.
6. Validated the 'Standard Accrual' seeded SL Accounting Method
7. Created Responsibilities and linked them to the ledger and the OU
8. Created Bank Accounts in the above legal entity and OU
9. Created User, Employee and linked the above. I linked the job 'MGR500.Manager' to the employee.
10. Attached the responsibilities to the user
11. Created and approved the PO.
12. Entered receipts
13. Created and validated accounting entries for the receipt. (Basic entries, no taxes)
14. Set up AP.
15. Entered invoice and matched it to receipt. Validated, Created Accounting entries and entered payments.
16. Created accounting for payments

What else did I do?

Ran the 'Validate Application Accounting Definition' process from purchasing (you can also run it from AP) for the combination of the new ledger and Subledger accounting method 'Standard Accrual'. This process will take some time.

Created Approval Groups and Approval Assignments in Purchasing.

Ran the 'Fill Employee Hierarchy' Process from Purchasing module after creating the employee.

What I did not do?

Create 'Final' accounting entries and transfer the same to GL. But that is a straight forward process.
I also did not test the tax engine in R12.

Future plan...

Test the above cycle in OPM scenario.

I am hoping to update the blog with the process test steps and key learnings soon....

New Poll

2007-11-12T11:36:00.000+05:30

Very disappointing participation in the previous poll. But will I give up? NO...
The question for the new poll is the one on the best matric to evaluate ERP. What according to you is the best matric? By design I am forcing you to choose a single option. Of course, you would love to give more than one option, I know.
But the idea is to find out what you, the consultant, think is the best matric that can be used to evaluate the success of an implementation perspective. You could look at it from the perspective of measurability and the impact for the customer. The options are given from the perspective of a normal manufacturing implementation.
Go on, air your views and let the world know what you think....
Probably the following article from my blog could help you decide....

New Feature - Poll

2007-10-06T09:57:00.000+05:30

As promised in one of my previous mails, I am adding a 'Poll' to my blog.

Each poll will be available for voting for 15 days.

The poll will give us a snapshot view of what our fellow ERP practitioners feel about the various debatable topics.

The poll is initiated with the 'mother' of all ERP topics. Is ERP really beneficial to business? There are as many views on this as there are ERP practitioners. There are multiple related questions including is ERP top management friendly at the cost of users?, is ERP as good as the consultants implementing the same?, is ERP a commodity etc. We will be taking up some of these questions in later polls.

In the meantime, let us start with the first step......

Please vote in this poll.... Let the world hear your voice...

Humour / Humor in ERP

2007-09-26T10:16:00.000+05:30

Guys, I am sure that each one of you would have come across a number of funny moments - some amusing, some hilarious - during your ERP implementation. These are some of the experiences that you can discuss with buddies over a beer and have a good laugh. I have come across many such instances which I will pen down as and when I remember.

Why don't you share with me through this medium some of those moments so that we all can share a good e-laugh?

Here goes the first one.

Well, this is not exactly my experience but that of a friend of mine. It happened around 5 years ago, I think

They (my friend and his team) were implementing ERP in a manufacturing company located in an interior village in one of the backward states in India. The place was relatively lonely and there was a team member in the implementation team who used to while away the time by browsing over porn sites in the net. Every site he visited downloaded cookies into his PC. In a span of over a month, this guy had accumulated so many cookies which if it were to be counted in currency, would have made him a millionaire.
This guy went on a holiday for 15 days. During this time the team planned the CRP (Conference Room Pilot) for the project. Since they had a problem with machine availability, they decided to use his machine which was the only one free.
The CRP was well hyped up and on the appointed day, the Conference room was relatively filled with users. The project manager, who was supposed to initiate the CRP, logged into my friends machine.
The moment he logged in, the cookies started their work.
Suddenly the wide screen (which was supposed to demo ERP) was filled with pictures of various female bodies in different stages of nudity. If at one corner suddenly popped out this Pamela like sexy siren covering her significant body parts with the thumbs of her hands, the middle of the screen showed this inviting blonde wearing only one piece of a two piece bikini. As soon as she vanished from the screen, she was replaced by this black brunette looking alluring in her side nudity......
There were blondes, there were brunettes, there were Indians, there were chinese, there were tall models, there were short models, there were whites, blacks and all shades in between.
There were two things in common between all of them. One, they were all women, and all of them had an acute antipathy to clothes of any kind.
Needless to say, among these nice, kind hearted and simple users (fortunately, my friend says, all of them were men. He can't even imagine the embarassment that would have been caused if at least one woman was present in the highly conservative audience) this dramatic display of 'Full Monty's' created quite a stir. Word went around that ERP showed sex.
Suddenly there was a dramatic increase in the interest in CRP and the CRP was a roaring success. Thanks to this incident there was a lot more active participation in the project and the curiosity created by this incident led to more widespread exploration of the product. All this, while it lasted, created lasting beneficial impact on the project.....

Who says sex and ERP do not gel together?

A good article on E Branding yourself

2007-09-25T12:49:00.000+05:30

I am not sure if this article is appropriate for this blog. But since we are all trying to improve our careers and trying to 'reinvent' ourselves, I thought this is very apt for this forum.
This talks of how you can e - brand ourselves by the tools provided for by internet.
I found this article very useful.

200 hits in the blog!!

2007-09-25T12:39:00.001+05:30

Some time last fortnight, without my knowledge, this blog achieved 200 hits. I thought it was a major milestone worth sharing with you all.
Considering that this was achieved without any marketing from my side shows that there are articles in this blog which are relevant and useful to ERP consultants worldwide. It is very satisfying to be of benefit to fellow professionals.
One complaint though. I would like to get to know your opinions about the blog. Its layout, the articles - was the content useful, was it complete, any suggestions for improvement, anything...
The 200th hit has motivated me to complete the current set of pending articles - I know a few are pending - and improve the blog and add more links to useful sites.
The future plan also includes starting a Q&A sessions where you could post the queries and we can try to find answers together.
It is gratifying to note that when I did a search on a few ERP topics 'Data migration strategy in ERP', 'Opening Balance Intake strategy in ERP' etc, this blog came in the first page of Google Search.
Thanks a lot for the support, guys and ladies. Please keep this up so that we can implement ERP successfully together.

Product Demo: A great way to introduce your team

2007-09-21T16:39:00.000+05:30

Product demo is one of the first activities that you tend to perform in an implementation. In an Oracle Apps implementation for example, the product demo is done in a demo database called 'Vision Demo Database'. This is a preconfigured database with all the standard flows built in to a significant level of detail.

In my experience, the implementation team takes this phase very lightly. For them this is a phase where you put in some stop gap consultants and ask the customer to go through the user manuals and aquaint themselves. For the customer also this phase is like an interval, the period of time before the actual 'real' activities start.

The implementation team starts the vision demo is by using the existing data and minimally tuning it to the customer's requirements. For example, you may create a supplier named 'Test Supplier' and a few items like 'Test Item' etc. Some of the standard processes are demonstrated in a demo company called 'Vision Operations'. The customer users who start the demo very eagerly, quickly lose interest in the procedings since they are not able to identify with the data!

The end result is that the implementation team has lost out on a fantastic opportunity to gain the confidence of the customer. Since the customer confidence in the product and the implementation team is a prerequisite to successful implementation, the 'real' activities of the project will start with the baggage of a sceptical or a 'neutral' customer as against a possible 'convert'.

The best way to use the Vision Demo effectively is to create a set of the customer's configuration in the Vision instance. For example, you could create an Organization as the customer's organization and link their set of books to the organization. Use actual suppliers, actual customers, actual invoices, payments, actual users etc. Most importantly, use actual items and actual warehouses where they will be transacted.

To improve the effectiveness, you could create the financial reports with the customer's chart of accounts and take out the actual financial reports after posting the transactions to GL. Nothing inspires more confidence in the project than seeing your actual financial transactions being recorded correctly. This inspires confidence in the finance team who will be one of the signatories to almost all the deliverables in the project.

I have moved!!

2007-08-31T22:42:00.000+05:30

Very hectic week.
I have moved to Oracle Corporation as 'Senior Principal Consultant' at their operations at Oracle Solution Services India Private Limited.
I am very excited and am keenly looking forward to the opportunity of working with Oracle.
Getting used to the organization and my new colleagues. Of course, I have quite a few friends in the organization.
Wish me luck in my new assignment!!

House shifting analogy for ERP implementation

2007-07-30T05:51:00.000+05:30

Being Developed

Design of Nominal Accounts in ERP Environment - Being developed

2007-07-28T07:14:00.000+05:30

An efficiently designed CoA can fulfill your following objectives:
1. Scalability
2. Simplicity
3. Is Logical

With these objectives in mind, I am giving below some guidelines in designing your CoA. These guidelines can be useful if you are moving into ERP since this gives you an opportunity to start afreash.

Length of the account: 6
Character type: Alphanumeric
Account Starting with :
1. Assets
11. Fixed Assets
111 L&B
112 P&M
113 F&F
114 CE
115 Vehicles
12 Current Assets
13 Investments, Loans and Advances
19 Intangible Assets
2 Liabilities
21 Current Liabilities
22 Short term loans
23 Long term loans repayable in one year
24 Long term loans
28 Provisions and Contingencies
3 Share capital and OE
31 Share Capital
32 Share premium account
33 Retained earnings
39 Minority Interest
4 Revenue
41 Income from operations
49 Other income
5 Costs of operations
6 SG&A Costs
7 Depreciation, Amortization and Finance costs
8 Suspense, rounding error, minority interest and others
9 ERP Contra Accounts

The last group is very important in an ERP environment. The contra accounts are a group of accounts which are to be set up in ERP scenario. Most of these accounts are not present / available in a traditional CoA. ERP maintains these accounts to handle the timing and module difference in the accounting impacts of various transactions. ERP ensures that the net balance in these accounts is zero at the end of a transaction cycle. Hence any balance at the period end in these accounts imply that a) some transcation cycle is yet to be completed in the current period b) bug in the program or c) incomplete set ups.

Normally these accounts do not get monitored periodically due to two factors. First of all these are balance sheet accounts which do not get the correct focus in a P&L focussed analysis. Another reason for poor monitoring is the unfamiliarity of the finance team with these accounts. The net impact is that there is huge balance lying in these accounts which raises some uncomfortable questions from the auditor.

Grouping these accounts ensures that these accounts are reconciled periodically along with the period close. This helps in ensuring financial integrity as well as certifying the system as bug free.

Opening Balance Intake Strategy in ERP

2007-07-21T09:15:00.000+05:30

This is going to be updated soon

Data Migration Strategies in ERP

2007-07-16T12:55:00.001+05:30

Read my White Paper in IT Tool Box

Introduction:

Along with optimum design of chart of account structure, effective and efficient migration of data is one of the cornerstones for the success or failure of an ERP implementation. Since a number of questions need to be answered and decisions need to be taken before loading the data into the ERP, significant amount of planning need to go into before the data is migrated into ERP.

However, in practice this do not happen to be the case. Since data migration is the last activity before go live of an ERP implementation, this very important activity is subject to acute time constraint. With the top management demanding the timely roll out of the ERP, planning for data migration becomes the premier casualty. This results in junk data going into the new ERP system thereby making the whole implementation suboptimal from day one.

The upshot is clogged database tables, reduction in disk space, performance issues, confused users who are entrusted to clean up junk data in the new system (without much familiarity with the product and the processes) leading to the GIGO phenomenon!. It is not long before the stakeholders lose faith in ERP.

Given this context, the article aims to provide a higher level view of the data migration strategy to be followed in an ERP implementation. The article illustrates some of the points using Oracle Applications as the ERP product owing to the author's familiarity with the product.

Data Migration Strategy

The data migration strategy consists of the following:

1. Identifying the data to be migrated
2. Determining the timing of data migration
3. Generating the data templates
4. Freezing the tools for data migration
5. Deciding on migration related setups.

6. Deciding on data archiving.

The data to be migrated
The data to be migrated to Oracle Applications consists of four groups of data. These data need to be entered in the given order since each of these groups are dependent on the data entered in the previous step. They are:

1. Configuration data (Set up data): Here the general principles and processes to be followed by the system are defined. This is a one time data entry and is predominantly entered manually. The key points to be considered while entering the setup data is the scalability requirement if additional countries are expected to link to the instance at a later point in time.
2. Sub Master Data: These are primarily the set of transaction related policies and rules followed in the organization. These include, among others, the payment terms, the delivery terms, the delivery methods etc. These data is normally a one time entry and predominantly entered manually.
3. Master data: The master data is a list of regularly updatable entities that the organization is expected to use in day to day transactions. These include, among others, supplier master, customer master, chart of account master (for each segment), banks master, currency master, region master, country master, location master, tax master etc. The principle feature of the master data is the extensibility of data. These are in the nature of transactional data and will need regular updates and maintenance. The mode of data entry will depend on the data volume. Predominantly, different tools are used to load the master data into the application.
Localization requirements form an important part of the master data. It has to be ensured that the templates being used to load master data collects the localization information relating to each master entity.
Since master data is subjected to regular updates, it is prudent to load the master data very close to the go live date.
4. Transaction Data: Completion of transaction data entry is normally called as ‘System Go Live’. The transaction data normally consists of the supplier balances, the customer balances, the trial balance, the assets master etc. Since the entry of open balances have financial implications, the above data entry is subject to a series of decisions. The decision include loading open balances versus loading both the open and closed transactions, the archiving requirement, whether to resolve the disputed transactions before or after data migration, whether to post the migrated balances to GL and finally the strategy for validation of data entered into the system. This is a one time data entry and is normally tool based data load.

Timing of data load
As far as timing of data load is concerned each of the above data follows different time lines. Normally the set up data is completed and signed off before the conference room pilots are completed so that the UAT is conducted in an environment similar to the production environment. Since some of the setup data cannot be modified once it is entered (for example the Accounting Calendar), a lot of care need to be taken before entering the setup data in the system. It is a very good practice to follow a version controlled documentation for the setup data.

Since the sub masters are also one time data entry, these will follow the same process discussed for set up data mentioned above. However, since the sub masters are OU specific, separate data load process need to be used for each OU.

As discussed in the section on data, the master data are subject to continuous updates. Hence the strategy to be followed for master data consists of incremental load as the process moves from CRP1 through UAT. The primary objective of the incremental data entry is to test the completeness of the templates. This means that every load of the master data should be used to test the tools and the templates in addition to the data itself.

The transaction data can also follow the same data load process as the master data. Since the transaction data has accounting implications, it is suggested that every load of transaction data test the whole data load cycle including transferring to GL and validating the accounting entries.

Templates to be used
These are sharable components that can be used for data migration of different countries into the regional instance. The template should be designed to handle three sets of data.

The first set of data is mandatory for the database. These include the primary key values like supplier id, customer id etc. These are unique values.

The second set of the data is required for the effective performance of the application in the organization context. These are organization specific data and could include values like payment terms, delivery terms etc. These are not mandatory for the application to function.

The third set of data is the country specific data. Since the country specific data could be different across countries, the template need to be suitably modified for each country.

As was the case with master data, it is best to freeze the template at the initial phase of the project and test its utility at different phases of the project. This will help in identifying missing data requirements long before the final go live date.

Tools to be used
Four different tools can be used to load data into the oracle database. We could use different tools for different types of data.

1. Desktop Integration: Data Loader can be used as tool which can be used to load data into the oracle tables. Optimally this tool is used in cases where only a single window is used to enter data in case of a manual entry. The tool is easy to use and is very flexible. Some of the data that can be loaded using this tool include chart of accounts, and some of the sub masters. The advantage of this tool is that the consultant do not need technical expertise to load data into the system.
2. SQL Loader: This tool picks data from a data file in a specific format (‘.csv’) and loads it into the staging table. From here the data can be moved to the base application tables using SQL Scripts.
3. Oracle Standard APIs: These are program interfaces provided by Oracle to load standard data into the base application tables.
4. Custom Built Interfaces: These need to be developed for non standard data that need to be loaded into the database
5. Custom Built Forms: The problem with all the methods described above relate to significant requirement for technical knowledge. It will be a good idea to spent effort in developing custom built forms to load data into the database. This is similar to the ‘Import Manager’ tool available in Peoplesoft. The effort spent on this will be well worth since this could act as a component which can be reused across implementations. The development of these forms is a separate project and is not covered within the scope of this document.

Each of these tools need to be evaluated from the perspective of speed, scope of errors and data volume.

Migration related setups
Based on the strategy for data migration, a few setups need to be created specifically related to data migration. These setups can be end dated after the completion of data migration.

1. Creation of new account codes: A few opening balance intake accounts need to be set up. These accounts get one side of the balance from the sub modules and get the balancing value from the GL trial balance. The accounts include Payables Open Intake Account, Receivables Open Intake account, Assets Open Intake Accounts etc. It should be noted that the creation of the account codes will depend on the migration strategy (specifically whether the transactions taken into the system are going to be posted to GL or not).
2. Setups in AR: Depending on the auto accounting setup in AR, you may need to create separate transaction types or standard memo lines for taking in receivables opening balances. This also depends on the standardization of auto accounting setup across countries in the regional instance.

Data Archiving
Decision on data archiving is dependent on various factors including the statutory requirements of various countries, reporting requirements and transactional information requirements. For statutory requirements some countries are expected to maintain up to 7 years of data. Also, the organization may want refer to some older data for internal auditing and comparison purposes and finally users may want to refer back to more recent transactions.

Based on each of the above, the archiving period will vary. While statutory reporting may require 7 years of data, comparison reporting may call for 4 to 5 years of data and transactional requirements will call for the last one year's data.

In data archiving, the organization could follow any of the following strategies. The issue of data archiving is applicable to the intake of transactional data discussed earlier.

1. Do not load any past and closed data into Oracle Applications. Import only opening balances:

For AR and AP, import only the current balances in the respective control accounts. For any partially completed transactions, import only the open balances. Close out as many transactions as possible by paying off AP invoices for example. By making the data compact, this method is easier to apply and is intuitive. The major advantage of this method is that the organization can do a data clean up exercise before loading the data to Oracle. However the drawback of the above approach is as follows.
a. Historical transactions will not be available in oracle for statutory requirements: Some countries require 7 years of archived data. This information will not be available in Oracle if the above method is followed. The way to handle this is to either have an archive instance with the historic data or to back up the historic data in an archive databases and have some of the key reports prepared in discoverer pointing to the database.
b.Transactional linkages will not be available: Some of the current transactions may require the user to track back to some older transactions. In the above approach, the past transactional information will not be available
2. Load only the past data corresponding to the current transactions:

In this method, load all the transactional data relating to current open balances. For instance, if you have a partially paid invoice, enter the original invoice and the partial payments into Oracle. Most of the time, this takes care of user’s requirements discussed above.
3. Load all the data from the legacy system to Oracle:

There is no data cleaning in this method. This is more like a data dump from legacy system to Oracle. In addition to increasing the disk requirements, this leads to duplication of data as well as performance issues.

For options 1 and 2, the organization will have to consider an instance strategy for archive instance as a part of the detailed instance strategy. The instance strategy should involve the infrastructure as well as the MIS reporting linkages in addition to the archived data.

Conclusion

Data migration is the most important activity determining the success of an ERP implementation. An accurately migrated data is a demonstration to the stakeholders that the ERP system is a reflection of their current organization. This increases their confidence in the system and in turn is a key factor in the ultimate success of ERP implementation. In many instances, this important activity do not get the kind of serious attention that it deserves.

However by following a well laid out data migration strategy, organizations can ensure an effective and efficient data migration.

Global Single Instance: Challenges

2007-06-12T20:10:00.000+05:30

As the organization moves towards a Global Single Instance, there are four phases that it has to cross. Each phase builds on the previous one. The phases are:
1. Database Consolidation: The various databases which are spread across various instances are moved into a single data center. In this process all the databases exist as they are, but in a single data center. This enables reduction in database admin costs. This is just location consolidation.
2. Technical Consolidation: In this phase, all the different databases are moved into a single database instance. In this case the benifits include further reduciton in cost and improved access to database. Some of the challenges include UTF8.
3. Process standardisation: Here you identify the common processes and your local processes. Try to integrate these and try to bring in as much process standardization as possible. This leads to common parameters for comparison, reduction in costs and a 'single internal view' of the organization.
4. Shared Support / Service Center: This is the highest level of consolidation where you are supporting multiple country users from your single shared service center. Main benefit is the reduction in service expertise duplication.

The main challenges in this endeavour include:
1. Setup: How do you determine the global set up and local set up ? How do you bring a buy in for the global set ups? How do you determine the set ups since they are linked to processes? How do you handle set up changes based on process changes?
2. Migration: How do you structure your migration? Issues involve data structure differences, Transaction types, Primary & Foreign key mappings etc. , How many test migrations, User involvement, when should you migrate (after period end?), How many instances should be migrated at a single time, How do you handle historical data, How much of historical data needed etc...
3.Data Integrity: How do you ensure data quality? How much of data quality to aim for? How much of cleaning to be done etc..
4. Performance Issues: System performance is what the user faces. This need to be checked thoroughly during UAT. Plan should be in place to ensure that any additional hardware requirements are brought in when needed. Migration related performance applies to handling huge volume of data during migration. This leads to a question of number of parallel consolidations, regional consolidation v/s global consolidation and duplicate consolidation etc. And finally the third part of consolidation relates to the performance of consolidated entity and how to ensure optimal performance.

A very good article on how Oracle went about moving to a global single instance can be found here.

Accounting Flows in Oracle Applications

2007-06-02T14:12:00.000+05:30

Given below are the accounting entries generated by ERP in case of Procure to Pay, Production and Order to Cash Cycles. This is given in the the context of OPM being used in the implementation.

Cycle: Procure to Pay

1. Enter PO: Accounting Impact Nil
2. Enter a receipt:
-------------Debit --------Inventory Receiving Account
-------------Credit-------- AP Accrual Account
3. Inspect and Accept: Accounting Impact Nil
4. Delivery to stock:
-------------Debit ---------Inventory Account
-------------Credit --------Inventory receiving account (ISP)
5. Enter PO Matched Invoice
-------------Debit ---------AP Accrual Account
-------------Credit --------Supplier Liability Control Account
6. Enter payments against the invoice
-------------Debit ---------Supplier Liability Account
-------------Credit --------Cash / Bank Account

As can be seen inventory receiving account which gets debited in step 2 above, gets reversed in step 4. This is an account required by the ERP and may not be found in the standard chart of accounts of the organization. Balance in this account implies that either the received items are yet to be delivered to the store (Quantity is not available in stores) or that the accounting entries in step 4 have not yet been posted to GL. In the OPM scenario, since the posting to GL takes place at month end, the second reason is most likely the cause of balances in this account.

The finance user normally takes some time before he clearly understands the significance of this account. This is a contra to inventory account and hence is to be considered as a balance sheet account. The above two factors vis. the non familiarity of the user and this being a balance sheet account means that in a P&L focussed accounting environment, this account generally goes unobserved and sometime piles up huge balances which causes much heartburn at year end when the auditor asks some probing questions.

This account is set up for each receiving organization and is set up in the purchasing module under receiving options.

Another contra account is the AP Accrual Account. This is the contra to the liability and it recognizes an accrued liability where the incidence is not clear. In India sometimes this account is called 'Provision for purchases'. This account will get a credit entry in step 2 and will get reversed in step 5 when PO Matched invoice is entered in the system. As this implies, the balance in this account means that PO Matched invoices are not entered in the system or that the accounting entries for those invoices are not transferred to GL.

In OPM scenario, this account gets picked form the account mapping in OPM Cost Management module under MAC (Manufacturing Accounting Controller) set up for account title 'AAP'.

Supplier liability account is the Creditor Account, commonly called as 'Sundry Creditors' in India. In Oracle it is called the A P Liability account. This account is set up when you set up the supplier site information in Oracle Purchasing / AP.

Bank / Cash account is linked to the bank that you set up in AP.

In OPM Scenario, the Inventory Account is mapped in OPM Cost management module under MAC set up for account title 'INV'

The accounting entries mentioned in step 2 above automatically move to GL interface table on creation. These will be available in the GL Interface table under the source 'Purchasing'. These entries move to GL Journal tables when you run the import journals program in GL for that period and that source

The accounting entries in step 4 will be generated in OPM MAC under Document type 'PORC' and will get generated when you run the 'Subledger Update' Process and will be moved to GL interface when you run the GL update process in OPM MAC. These will be available in the GL interface table under source 'Purchasing /OPM'. These entries move to GL Journal tables when you run the import journals program in GL for that period and that source

The accounting entries generated in step 5 and 6 above will move to GL Interface when you run the 'Payables Transfer to GL' process in AP. While the entries in step 5 will lie under source 'AP Invoices' (this need to be validated), those in step 6 will lie under source 'AP Payments' (this need to be validated). The payables transfer to GL allows you to automatically move the entries to GL journal tables.

Cycle: OPM Manufacturing

1. Batch Release
----------Debit --------WIP
----------Credit -------Inventory
2. Step certification
----------Debit --------WIP
----------Credit -------RCA
3. Batch Certification
----------Debit --------Inventory
----------Credit -------WIP
4. Batch Close
----------Debit / Credit ------WIP
----------Credit / Debit ------CLS

All the above accounts WIP, RCA and CLS are set up in OPM Cost Management module under MAC set up.

RCA is otherwise known as 'Overhead absorption control account'. This is normally a P&L Account and a credit to this account implies that the overheads used in production are absorbed by the finished product inventory and hence the finished product inventory value has gone up. This gets reversed when the actual overhead expenses (wages, power, water, rent etc) are expensed in the month end.

Since RCA is a P&L account with a credit balance, this could temporarily inflate the profits of the organization. The consultant should clearly understand the significance of this account which is normally used by the cost accountants.

CLS is the the 'WIP clearing account'. This normally gets a balance in the standard costing scenario if the sum of the costs of the raw materials and the resources is different from the standard cost of the finished product. This account can also get a balance in the OPM PMAC (Period Moving Average Costing) scenario when a batch is released in one costing period and completed / closed in the next account period. In such scenario, this account is to be clubbed with WIP.

The accounting entries in the above 4 steps will be generated in OPM MAC under Document type 'PROD' and will get generated when you run the 'Subledger Update' Process and will be moved to GL interface when you run the GL update process in OPM MAC. These will be available in the GL interface table under source 'OPM Production Management'. These entries move to GL Journal tables when you run the import journals program in GL for that period and that source.

Cycle: Order to Cash

1. Enter Sales Order: Accounting impact Nil
2. Ship items
-----------Debit ---------PCO
-----------Credit --------Inventory
3. Enter invoice
-----------Debit ---------Receivables
-----------Credit --------Revenue
4. Enter receipts
-----------Debit ---------Cash / Bank
-----------Credit --------Accounts Receivables

PCO is set up in OPM MAC. It is also called the COGS (Cost of Goods Sold) account. This consists of two parts: Cost of materials sold (normally known as material consumption) and cost of Overheads (Overheads consumption). Through the use of 'Selection Priority' MAC allows you to direct the accounting entries to different accounts thereby making the preparation of P&L reports much easier.

Accounts receivables (also known as 'Sundry Debtors' in India) and Revenue Accounts are set up in the Accounts Receivables module. The autoaccounting set up feature in Oracle AR provides a lot of flexibility to consultant to account different transactions through different accounting rules if required.

Note: Oracle Provides a lot of flexibility to the consultant in accounting the transactions. However it is better to stick to knittings and provide a simple and intuitive accounting solution rather than using a lot of accounting rules which could increase the intensity of training and knowledge transfer requirement in the organization.

The accounting entries in step 2 above will be generated in OPM MAC under Document type 'OMSO' and will get generated when you run the 'Subledger Update' Process and will be moved to GL interface when you run the GL update process in OPM MAC. These will be available in the GL interface table under source 'OPM Order Management'. These entries move to GL Journal tables when you run the import journals program in GL for that period and that source.

The accounting entries in step 3 and 4 above will be generated in Accounts receivables modules and will move to GL Interface table when you run the 'GL Transfer' Program in AR. While the entries in step 3 will lie under source 'Invoices' (Need to be validated), those under 4 will lie under source 'Receipts' (Need to be validated). These entries move to GL Journal tables when you run the import journals program in GL for that period and that source.

And finally , the 'Posting' process in GL moves all the transactions from GL journal tables to the GL Balances Table from where you can print out all the required financial reports.

Letter to CFO

2007-05-30T10:41:00.000+05:30

Read my Whitepaper in ITToolBox

Dear Maa'm,
Congratulations on finally choosing the ERP product and an implementation partner!!
No wonder you are heaving a sigh of relief. The last few months have been hectic for you, hasn't it? Endless negotiations with various product vendors each claiming their product superiority, endless negotiations with the system integrators, each trying to prove that their implementations capabilities are the best in business, endless internal meetings and discussion trying to sell the concept of ERP, discussions on hardware, software, team composition, resource requirements, budgeting, convincing the top management, streamlining the finance practices of the newly acquired companies, travel....
Wow!! no wonder you are wearing that sigh of relief on your sleeve.
Now it is very easy, isn't it? You just have to implement the product and stabilize this. Isn't that what we IT Companies are experts at? Implementation should not be that hard?
Pardon me for saying this, but what you went through in the ERP implementation process was cakewalk compared to what you are about to be in.
You have a challenge ahead of you. Of course, I know that that is what you relish. If not properly handled an ERP implementation can explode on your face leaving you with a sullied reputation and your organization in a confused mess.
It has happened before. It need not happen that way in your case.
By ensuring that business and not IT owns the project, you have started brilliantly. It has been found that 90% of project succeed if they are owned by the business against 50% owned by IT. That is good news.
There are a few golden rules that you must follow to make your implementation successful. Below in this article I am giving you a set of 15 such guidelines.
1. Have a clearly defined ERP philosophy: Think through your ERP implementation philosophy. Every ERP implementation is a conflict between process requirements which calls for customization and future product upgrade requirements which call for a vanilla implementation. Have a clear idea as to how you will handle the situation if it occurs. You could probably make a statement like " while reports customization is acceptable, the business users must make a strong case for any move away from the product features. The users will have to give the current feature available in the project, the expected feature, the cost benefit of the new process and the implementation consultant should sign off saying that such feature is not available in the product and that a workaround is not possible. Each process customization request should go thru a change request process which involve a review by the top management team."
In one of the projects that I worked on, the philosophy was clearly documented and read like "We understand that Oracle applications comes with best of breed processes which we want to implement in our organization. We are prepared to make the necessary sacrifices in terms of internal process changes to ensure that our processes meet the requirements of ERP". While this may be an extreme case, you get the point.
2. Hype it up: You are the CFO and not a marketing person. You are comfortable in the world of debits and credits and do not possess expertise in marketing. However remember that ERP entails change in the roots of of the organization. Every one in the organization is impacted. It is your duty to hype up the implementation to let the organization get ready for change. First aspect of hype is selecting the project name. Have a flashy name that every one can easily relate to. Names like 'Spotlight' and 'Transform' are passe. Have a name which communicates spirit and optimism to the organization. Spend some time on this. Having a competition in the organization to select the name is a good idea.
For continuous communication, use company newsletter and other avenues extensively. If possible start a separate news letter for your ERP implementation. Ensure wide circulation. Ensure that the organization never gets tired of hearing about your ERP implementation.
Other than those mentioned above, use the common tools like team lunches, incentives etc to ensure the hype. Your team deserves to be widely known.
3. Ensure scalability: Think through all the possibilities by which you are planning to grow. It could be organic and inorganic growth. It could be different units in the same country or different units in different countries. They may have different accounting conventions and different statutory requirements. Ensure that your implementation covers all aspects. In one of the implementations that I know, different units were kept under different business groups in Oracle. Since employees are linked at the business group level, they had severe problem handling senior managers (like CFO) who were common to all units. Ensure that you have only one business group created for your implementation.
4. Identify your key implementation objectives: This normally comes in the form of a structured statements in three parts. First part involves noting down your three main problem areas. It could be a) Period closing, consolidation and statutory reporting requirements due to your acquisition plans, b) Need for scalability due to the above reason and c) Effective project accounting to ensure correct project profitability. Second aspect is identifying the correct matrices and the current values for the same. For example for the first problem mentioned above, the matrices could be number of days taken to close the period (currently 10 days), number of days for consolidation to be prepared after the last entity is closed (another 5 days) etc.
The third aspect is to decide on the benchmark values for the above matrices. Involve the implementation consultant in this exercise and get his views. Never forget to sign off these KPIs or at least ensure that the consultants commit to these matrices from day one.

Have seperate set of matrices for Finance and HR.
5. Decide on your chart of accounts: In case you are going to rollout the ERP across countries, it is a good idea to have a global chart of accounts and control access to country specific accounts using 'Security rules' available in your ERP package. The Global CoA could be a superset of all the accounts likely to be used in all the countries. For example the nominal account used for Service tax interim recovery in India will remain in the same CoA as the withholding tax account you are using in Canada. Remember to start very early in the exercise and document all your plans and actions. Make sure to create the security rule matrix linking the responsibility to the Chart of Account values very early in your implementation.
6. Select a good team: The project team comprises of the implementation consultants and the core team from your organization. Since you own the project, you have to ensure that the team as a whole has the requisite qualifications. For example, if your implementation is driven from finance process improvement perspective, you have to have implementation consultant who is qualified in Finance. At least make sure that you have well qualified and experienced consultants who can achieve the key implementation objectives mentioned above in point 4. Remember that quality of the team is your responsibility.
A key parameter in selecting consultants is their ability to patiently train the users. You must ensure that the team that you have is very passionate about knowledge transfer. Incentivize the training. Make sure to recognize those trainers who do a good job. Along with this, you must ensure that the trainees also receive good value from their training. It may be a good idea to have all the training sessions ending with a quick test to see how much users have imbibed. This is especially applicable to the core team since they are going to train the other users in your organization.
7. Spend a lot of time on set of books and organization structure: Normally it is recommended that you use a single set of books if the units share the same calendar, currency and Chart of Accounts (3Cs). This causes two constraints vis. Closing a period in one business unit closes the entire set of books and document sequencing ie. the logic that generates invoice numbers, payment voucher numbers etc is decided at a set of books level. I have seen projects where the western region is not able to close its books since the east and north have not closed theirs because all of them are in same set of books. Probably this is not applicable in your case.
The easiest solution will be to have separate set of books for each business unit. This depends on whether the period closing is centrally done or is decentralized.
8. Involve your auditors from the beginning of the project: We are talking of finance systems and controls which need to be externally audited. It is a good idea for your auditor being a part of the steering committee so that he can ensure that all the controls are put in place from an audit and control perspective. The flip side of having an auditor is that the control of the project could shift to the auditor and this is detrimental to the implementation. If you are selecting an auditor, ensure that she is exposed to your ERP product and its features. A good auditor can provide valuable inputs to your implementation based on her experience.
9. Plan data requirements early: In any ERP project, the customer is expected to provide four important inputs. 1. Product Configuration Inputs 2. Masters - Suppliers, Customers, Open POs and Open SOs for example, 3. Details of transactions - Open Payable Invoices, Open Receivable Invoices etc and 4. Test Scripts for product testing during CRP, UAT etc. For items 2 and 4 above, start preparing early - may be as soon as the implementation commences. You have to provide master information in templates which will be provided by your implementation partner. Ask him to provide you with the final version of template as soon as possible so that you can start collecting data in the required format. Mind you, most of the implementation teams will not have the correct template immediately available. Immediately availability of such template may be a signal that you have chosen the right partner for implementation.
Remember, you have to have as many masters as there are business units. So you will have a number of templates to fill up. Most of the implementations get delayed because the customer is not able to provide full and accurate data when required. Ensure that it does not happen to you.
Same is the case with test scripts. Most of the time, you see that test scripts test only the obvious transactions whereas they should focus on exceptions. These are normally the bottlenecks. Test for errors and exceptions. At least you will be ready when this happens after go live!!
10. Have clear reference values for comparison: Work on your KPIs for each process Keep them ready along with the expected improvement levels. This will help you validate the success / failure (touch wood!!) of your implementation. As you go on, try to improve upon the matrices over a period of time.
11. If you are going for a global roll out, work on the global template: You must have most of your setups and processes common across the organization and changes should be applicable only to specific local requirements. Work on the global template, sell it across the organization. Global template for example would mean a single chart of account, same payment terms, delivery terms, delivery method etc across the organization, same supplier categorization, same expense types , shipping methods, transporter etc..... These are called as sub masters in some ERP terminology. If possible make the customizations common across organizations. This exercise should consider the scalability and organizational growth requirements. You could call it ' (Your Company Name) Operating Framework' (Delta Operating Framework [DOF] for example). Remember that this is more than an ERP concept. It is a kind of cultural change that you could initiate through ERP.
12. Document, Document, Document: Drive your team (especially your core team) to specifically document their learning. Bring in a process of review at multiple layers of the project team and sign off so that the document moves to repository. Design appropriate incentives early in the project to document. In addition to the rigor it brings to the deliverables, it also ensures quicker knowledge transfer.
Another aspect associated with documentation is version controlling. Make some version control tools available at the beginning of the project. There are many such tools available as free downloads in the Internet.
13. Control timelines: You are dealing with multiple parties in an ERP implementation and every one will have his own requirements. Some of these are bound to cause scope creep and corresponding cost and time overruns. Watch the scope creep, make sure that it is kept to minimum. One way to do this is to demand from your core team that all their requirements must be documented and signed off during the AS IS discussion if you have one. (You may not need it if you are going for vanilla implementation or you may need only discussion on some of the management reports. ) Any scope changes after sign off of requirements doc should be considered as a Change Request and creation of CRs should be disincentivised.
14. Involve a third party consultant to oversee the timelines: It is a good idea to appoint a third party consultant to focus on the project plan and ensure that it is met stringently. He could also oversee the test plan preparation and UAT. This could work out to be highly cost effective.
15. And finally, Keep it simple: Simple is the way to go. If you have three ways of doing the same thing, go for the simplest. It may sound easy, but it is not so. There is a tendency among the implementation consultants to go for the solutions they are comfortable with, but which may not be simple. Unless you demand, you will not get simple solutions. One way to do this is to ask for minimum of three options for any problems that you face. Believe me, ERP provides this ability for most of the common problems. Have a 'Simplicity Quotient' defined with a reference value for most of your processes and try to better the reference value.
It makes some sense to stand back once in a while and see if your implementation is simple or it is acquiring 'creeping complexity'.

Conclusion:
An ERP implementation brings in a cultural shift in the organization. Unless handled carefully and thoroughly, there will be a tendency for it to go out of hand and the implementation landing in a mess. Most of the time, the proof of bad implementation is in the pudding of period end closure when all the accumulated mistakes pile up forcing you to do manual closure of your accounts.
Following the above 15 steps will ensure that your ERP implementation is highly successful.

Towards Global Chart of Accounts (Global CoA)

2007-05-17T10:42:00.000+05:30

Introduction

While setting up a global chart of accounts is a very beneficial objective for most of the organization, more often than not, it remains at at the stage of wishful thinking or ambition. Organizations bravely undertaking this virtuous objective often find themselves faced with gargantuan obstacles and tend to lose heart and give up in the formative stages of this exercise and decide to live with 'As Is'. The primary obstacle is the multifarious accounting conventions and taxation considerations in the various countries that they do business in.

However those organizations which persevere with this exercise and completes it reap rich rewards. The most obvious benefit of undertaking this exercise is the vastly expanded knowledge it provides to the organization about its processes. Companies often are surprised to find many common processes that were till then considered 'country specific'. This helps them to integrate processes across the organization in a more efficient way. Another benefit is that this exercise helps them rationalize their country specific processes. Some of the country specific regulations have become out dated and so have those country specific custom processes designed to meet these regulatory requirements. For instance, as India moves to a uniform GST, most of the India specific localizations that were catering to the India taxation regime will need to be removed, rewritten or relooked into. In this case for example, the separate GL nominal accounts created for meeting India specific processes become redundant as the Indian Taxation Regime smoothly integrates into the global taxation practices.

In the light of the above, this article attempts to provide a set of guidelines to the implementation team as they move towards designing a global chart of accounts. It starts by analysing the changing global business landscape that makes global CoA a necessity rather than a virtue. Next it identifies the common road blocks in the path to creating a Global Chart of Accounts and goes on to list down the benefits and drawbacks of a global CoA. The article concludes by providing a set of key implemenation considerations that could help the organizations as they decide to go through with this exercise.

Changes in Business Landscape
Over the last 20 years or so, the global business landscape has undergone tremendous changes. These have been catalysed by the phenomenal global economic growth, the rapid advent of IT that has eliminated the distance between countries and made 24*7 operations a normal scenario, and commoditization of ERP to name a few. Given below are a list of some of the key changes to the business global landscape that necessitates the introduction of 'Global Chart of Accounts' (Global CoA).
1. Globalization and Integration
This has been the lingering theme of the last 20 years or so. As globalization and the concommitent business integration marches on, the multinational organizations are faced with new and complex business processes and corresponding accounting challenges. For example, it is almost normal for an Indian company doing business in China, procuring its supplies from a german supplier and consolidating its payables in Indian Rupee. Here the challenges to payable accounting, inventory valuation and treasury management brings in complexities related to accounting conventions and methods followed in different countries.
2. Shared services becoming a norm rather than exception
As the global distances gets shorter, it has become a normal practice for organizations to pool and manage their operations like payables and receivables management from a shared service center located in a low cost country with requisite skill sets. Usually a single team in this country handles the operations of units located in different countries. In this situation, having multiple CoAs for different country operation could become a serious bottleneck.

3. Maturity of ERP Implementations
Over the last ten years or so, ERP has evolved as a major catalyst for organizations to standardize their processes. By forcing the organizations to take a hard look at their business processes, ERP has enabled the organizations to be aware of and bring out standard processes across their business units. The inflexibility of ERP has forced organizations to standardize their business processes in some cases. The realization is slowly dawning that while the process have standardized in most cases, the nature of accounting those processes is yet to catch up.
4. Dependence on WEB - Need for a single internal view of the organization While there are many benefits of Internet, the less talked about is the single view it has brought to the organization about its business. In the pre web period, the HQ of an organization has to wait a month to receive a few handpicked reports from its different international units to get a picture of the health of the organization. The advent of web has changed all that. Now the CFO sitting in Mumbai can receive real time reports of its Chinese, US and German operations on his laptop at the click of a mouse!!. In this scenario, it makes sense for the organization to have a single Global CoA for the CFO to make sense of those multifarious reports.
5. Increase in quantity and quality of M&As
Organizations growing through M&As find that the major challenge in the exercise is standardization of the processes by combining the best practices followed by the two organizations. Many a times they find a significant difference in the way they account similar transactions. One of the ways in which they try to bring about integration is by using common ERP systems. As discussed previously, a common ERP provides optimal results through process and accounting standardization.
6. New category of accounts created by ERP - Contra Accounts / Intercompany accounts / Cash Clearing accounts etc
This is one instance where ERP and not the business is the key reason for demanding Global CoA. Firms implementing ERP find exposed to a new group of accounts which is not presently available in their existing CoA. ERP expects these Contra accounts to be set up for all the implementing units. In many cases these accounts could hold significant balances and will require close monitoring and control. As most of these accounts are balance sheet account, their impact will not be immediatly felt in the P&L focussed analysis. Creation of these accounts is another reason for organizations to go for Global CoA.

However, be careful with Global CoA
While Global CoA is definitely a worthy objective, it is not very easy to achieve. In many cases organizations would have spent considerable amount of organizational time and resources in designing the present structure. Since the current CoA is designed with organizational requirement in mind, it is better to tread with caution while moving over to Global CoA. The consultant should take pains to understand the detailed design considerations behind the current CoA. He/She should put in place a clear cut stakeholder expectation management strategy while embarking on this exercise. All the stakeholders including Users, Management, External Auditors, Board and the Shareholders are comfortable with the present method of financial accounting and might not want to upset the applecart.
The strongest argument in favour of Global CoA is the change in global business landscape discussed earlier. It is possible that sooner rather than later, the organization will need to react to the changes. As they say 'it is better to prevent and prepare than repent and repair'.

Another argument is the creation of new set of contra accounts to meet ERP requirements and the concommittent control requirements.

Some of the arguments in favour of maintaining the status quo are as follows.
1. Significant customization in the current design
If the current system consists of a number of inbound and outbound data to and from the GL, the implementation of Global CoA will call for a detailed review of all these customizations. In that one of the main triggers of implementing Global CoA is planned ERP implementation, this will be a beneficial exercise since it helps to evaluate each interface with a view to retaining or discarding the same. However Global CoA will call for modifying most of these customizations.
2. Significant consolidation requirements
Firms using third party applications like Hyperion for consolidation will need to rewrite a number of account mapping rules prior to using Global CoA. Consultant will have to redesign these rules and get management sign off before commencing the process of implementing Global CoA.
3. Sensitivity of data.
Since the financial data is very sensitive to the organization, there will be a fear that the introduction of the new CoA could bring in increased number of accounting errors and finally could affect the financial reporting. Often this argument is proffered by a senior member of the organization who has been a part of failed ERP implementation in the past. The way to handle this is to do a thorough planning and design a pilot / prototype and get an organizational sign off.
4. Significant Local Exceptions
If the organization has operations in different countries with different statutory requirements, it could have an impact on the Global CoA. This requirement calls for creation of a set of country specific nominal accounts to handle the different tax regimes and hence may not be amenable to Global CoA. The challenge is to integrate the local tax accounts to the Global CoA.
However, the plus side is that as discussed earlier, the introduction of Global CoA provides an opportunity for the organizations review their country specific taxation processes. Many a time, they are able to rationalize the localization processes and reports thereby reaping significant scale advantage.
5. Intensity of training requirements
One of the key challenges in bringing out Global CoA is the intensity of training involved in rolling out the CoA across multiple units. This is all the more daunting if different units had different coding conventions in the past. For example the Hungary Operations may have their asset codes starting with 1, the Owner's equity starting with 2 and Liability starting with 3. However the UK unit will have a convention where liability accounts start with 1, assets start with 2 and revenue starting with 3. It is a serious training challenges to make all these units get accustomed to the Global CoA.
Major challenge no doubt. It is challenges like these that make the whole exercise worthwhile.
6. Different accounting conventions followed
This is another case where the difference in accounting conventions call for different accounts. Typical example is the way different countries handle inventory accounting. While ERP directly debits the asset account on purchase receipt, many countries requires the organization to debit the P&L and reflect the asset impact at the period end.
Looked at it closely, this is more of an argument for / against the process rather than the Global CoA. Isn't it?

Design Considerations
An impending ERP implementation can act as a catalyst in the organizations move to Global CoA. As a part of the ERP implementation the organization undertakes a detailed analysis to understand the process fit to ERP. This is the ideal time to initiate the process of Global CoA. For one, the organization is ready for a change. Additionally, there are a number of features in ERP which makes it easy to transition to Global CoA. Some of the points which facilitate a Global CoA during ERP implementation are as follows.
1. Additional best of breed features in ERP: There are various features in ERP which can make your transition to Global CoA necessary as well as smooth. One such feature in Oracle Applications is the concept of Set of books. As the name suggests the SOB can handle multiple books. This feature allows you to use the single CoA across multiple instances / implementation. This is a strong argument for a Global CoA.
2. Parent Child Hierarchy: Another feature is the concept of parent child hierarchy for reporting purposes. Most of the ERPs allows you to group your child accounts under different parent groups for reporting purposes. Since each child can be grouped under different parents for different reports, you need to use only one CoA for most of your reporting purposes. Of course, your parent child hierarchy will need effective design and constant monitoring.
3. Flexibility & scalability: It is a good idea to define a superset of the accounts in your organization which will include the normal account codes as well as country specific account codes. Having decided this, use the security rules provided in the package to ensure access control ensure the relevant user - account matrix. This will ensure each user group accesses only the account codes relevant to their unit. This control is required from the statutory requirmens such as SOX. Such security features are common for most of the ERPs.
One of the key considerations is scalability and upward compatibility. Ensure that the length of the account code is designed to handle future requirements. For example a 4 digit code, limits to your account number to a maximum of 9999. This may not meet the design criteria of scalability. Normally it is preferable to have 6 digits for an account number.
Additionally ensure to provide sufficient enough gaps between various groups so that additional account numbers can be inserted into the account group in future. For example, if, at present, your fixed asset account numbers are 666101 to 660120 (20 Nominals), you could start the current asset codes from 660151. This leaves 30 nominals for future purposes.
Another aspect of scalability relates to the future growth plans of the organization. If the organization is planning an inorganic growth strategy, the CoA should have the scale to handle the future M&A activities and the incorporation of the new companies into the existing CoA.
4. Create a team of COA Ambassadors: As discussed previously, the process of changing CoA is very sensitive and is fraught with many an obstacles. It is very important to have a team of CoA Champions from the customer organization who can own and implement the solution across organization. Their primary role will include coordinating the design of Global CoA, Concept Selling, providing execution support to the rollouts of Global CoA, planning the transition plan, coordinating the security, access and consolidation activities and finally to 'soothe the nerves' at different levels of organization.
5. Direct from the top: From the perspective of Finance department, this could be the most important initiative which can impact the future finance road map of the organization. It is very important that this initiative be owned and supported at the CFO level. This is not a transactional initiative. Through Global CoA you are attempting to integrate the finance processes and reports and it is imperative that this exercise be directed from top level in the organization.

Benefits
1. 'One View' of organization
2. Easy MIS reporting : Quick and easily understandable reporting
3. Quick consolidation - No fancy account mapping rules required.
4. Better management control throughout the life cycle of the chart of accounts
5. Process standardization should follow from CoA standardization.

Drawbacks
Excessive standardization: This could lead to lowering of the depth and breadth of the country specific data. Some of the taxation accounts are Balance Sheet accounts and hence are not as closely monitored as P&L Accounts. Chance of surprises could not be underestimated.
Need for close monitoring and tracking. The use / misuse of the new accounting codes due to unfamiliarity in the early phase of implementation calls for intensive training and handholding in the initial stages and an extended, process driven monitoring and tracking for a significant period of time.

Conclusion
As the organization prepare for its ERP implementation, it is a beneficial exercise to conduct a detailed review of the current chart of accounts. The review should include environmental analysis focusing on your industry trends, the industry future direction and your company’s current position and the aspired position in your industry. The other aspects to be considered include the current CoA dimensions and the future MIS requirements. The whole exercise is to be considered as a sub project within the scope of the ERP implementation and need to be handled by a team of domain specialists with support from the ERP consultants.
This exercise, if properly done, can reap rich dividend for the organization including a clear understanding of the future road map of the organization, thorough knowledge of the current accounting principles, processes, policies and standards (3PS) and lead to rationalization of these. The end result is a tightly knit organization flexible enough to handle local accounting exceptions.

Design Considerations in Set of Books

2007-05-10T11:10:00.000+05:30

There are some critical issues when designing a set of books in a multi OU scenario especially if the OUs operate in the same country.
For example, let us say that you want to create 4 OUs for the Indian Operations. Since the Chart of accounts, Calendar and Currency are the same, the standard procedure is to create a single set of books and link it to each of the OUs differentiating the OUs through the value of 'Company' segment in the chart of accounts.
However the above approach has two associated issues. The first issue is related to the period closing. While each OU tracks their receivables and payables separately, they would like to close the sub ledger periods once their transactions are completed. However this cannot be done in the above scenario since OUs are linked to the same set of books and closing the period in one OU will prevent other OUs from transacting further in the above set of books.
The implication is that in the above scenario, you can close the period only if you complete the transactions in all the OUs. This may not be acceptable to the customer.
Another issue is related to the 'Document Sequencing'. Since the document sequencing is set up at the SOB level, you cannot design different document sequencing rules for different OUs. In this scenario, for example, Payables Invoice No 10002 will pertain to OU1, 10003 to OU2 etc. This has significant audit and control issues and normally auditors object to this solution.
How do we handle this situation?
The solution is to have separate Set of Books for each of the above OUs and get the financial reports from a consolidated set of books which consolidates data from each of the above set of books. Though it appears complex, this is in reality a very simple solution from mapping point of view.
However there are some problems associated with this solution. First of all, this is counter intuitive. If you look at it carefully, this is equivalant to the OUs maintaining their independent books and hence goes against the concept of 'set' of books. In addition, you have to do period closing for multiple set of books and also for the consolidated set of books. Since the consolidated set of books is not the responsibility of any OU, it might get neglected.
Another related issue is the intense knowledge transfer required in the above scenario. There should be a clear KT processes in place to replace the user in charge of running the consolidation process.

Design Considerations for item coding

2007-05-08T10:32:00.000+05:30

Read my White Paper on this subject in IT Tool Box

Introduction
-------------
Intelligent coding of inventory items is one of the most important activities in an ERP implementation for most of the manufacturing organizations. As they approach ERP, most of the organizations find that their inventory items have been wrongly coded or not coded at all. Further access control issues related to creation of new items are also identified. Many a times these problems are observed relating to Raw Material and Consummable item rather than finished product items. In addition they also find that the same items have been classified differently for different requirements.
The above issues lead to consequences including lack of control on the inventory items, wrong valuation of inventory, item duplication, wrong / mutually exclusive classification, organization receiving wrong picture of their inventory, lack of real time accurate inventory data etc. Most of these consequences play havoc with the downstream activities including production planning, inventory planning, MRP, available to promise, issues with tax authority etc to name a few.
The main advantage of ERP implementation, if properly done, is that it forces the organization to take a long and hard look at the way the inventory items enter, move through and move out of the organization leading to manifold benefits for all the stake holders in the organization.

Objective of this document
---------------------------
This document aims to provide the ERP Consultant with a set of design considerations and check points to ensure an optimal inventory coding for the purpose of ERP implementation.

Design considerations in inventory coding
------------------------------------------
1. Landscape analysis
Before undertaking the exercise, it is beneficial to look at the organization / project landscape. The key points include, the number of ERPs being used in the organization and the commonality of inventory items being used by these packages, the inventory coding constraints imposed by different ERP packages, the inventory reports provided by different ERP packages, the number of external applications presently available in the organization, the flow of inventory data between these applications and the corresponding constraints. Also consider the future ERP roadmap of the organization (are they planning any new ERP implementation for example) and the expected customization requirements.
2. Ensure that you are only a facilitator
At the outset it must be made clear to the organization that you are going to act as a facilitator in helping the organization to decide on the item coding. It is very important to set this expectation right at the beginning since there is a possibility that the organization may expect you to execute the inventory coding for them. However as a consultant you may not have a clear picture of the inventory related activities / transactions in the organization. Any coding of inventory without a clear picture of the above will lead to a suboptimal coding.
3. Start early.
As discussed in the introduction to this article, there are substantial issues related to inventory coding in most of the organizations. Along with this, different part of the inventory are owned by different set of stake holders who have their own internal coding conventions. Added to this, if you have complex coding conventions and large item master it spells a potentially risky situation from the implementation timeline point of view. Hence it is better to sensitize the organiztion of the importance of inventory coding as early as the project boot camp and follow up the progress in all the senior management meetings.
4. Involve senior management from the beginning.
There is a tendency in the organization to leave the responsibility of item coding to the middle management personnel in the materials management department. Eventhough they are the drivers of the whole exercise, they may not have the authority to demand output from the line departments. It is very much necessary that top management is involved in this exercise from day one to ensure success of the implementation. If possible, consider inventory coding as a sub project in the exercise of ERP implementation. The consultant must remember that while inventory coding is not a component of the standard ERP implementation plan, this is a critical activity which can derail the project schedules.
5. Involve Finance Department
In many organizations there is a tendency to look at inventory coding as a 'materials management' activity. However finance department is the key user of most of the granular reports related to inventory and consumption. Inventory is one of the key components of 'current assets' in many organization and accurate valuation of inventory has significant balance sheet and P&L implications. Finance department need to be extensively consulted before the commencement of the coding exercise. They should also be one of the agencies signing off on any deliverables related to the inventory coding program.
6. Start with the reports:
As a first step towards the inventory coding, a consultant need to take a look at the various management reports being used by the organization. There are multiple reports that an organizations top management requires to assess the financial health of the organization. These include Stock Quantity Ledger, Stock Transaction report, ABC Analysis Report, Stock Valuation report, Raw Material / Consummables Consumption report, Cost Sheet etc. A consultant need to be familiar with these reports especially the granularity of reporting, and the categorization of the data required in these reports. Some of the common categories include item type (RM, SFM, FG etc), purchase category (Local / Imported) etc.
7. What are the details required for querying the item?
Suppose the item required is 'Raw material item, diameter of 0.5 inch, used for customer 1, Imported, purchased from supplier 1 and used for a specific category of FG'. Here each of the details (known as segments in certain ERP product terminology) required to be captured for an item.
8. What are the details required to be captured in the inventory code?
In database terminology this process is known as normalization. Analyse the data in step 3 and decide which of them need to be captured in the inventory code and which of the details can be captured as attributes to the item. This calls for a detailed knowledge of the product and its features. In the above example, you may have to capture the value of Raw material segment, diameter segment and a unique 3-4 character running serial number need to be captured in the item code where as the other details could be moved to the attributes.
9. How many segments do the product allow?
Packages like Oracle allows multiple segments to be used in inventory coding. In the above example you can use segment 1 for item type (RM, FG, SFM etc), Segment 2 for diameter (0.25 inch, 0.5 inch etc) and segment 3 can be used for the running serial number. The advantage of this segmentation is that you can set default rules as well as validation rules to ensure that wrong combinations are used. This is not the normal practice of inventory coding and hence will call for increased training and communication effort from your side to familiarize the users to this approach. In the above example, an item may look like 'RM-50-001'
However some packages do not allow multiple segmentation. In this case, you have to ensure manual rules to delienate the segments. While this method is intutive, it will call for superior training to ensure that user errors are kept to a minimum. This is because, in this method it is difficult to set the kind of default validation rules that was set in case of multiple segments. In this method the above item will read as 'RM50001'.
A note of caution if you are using both Oracle discrete and Oracle process manufacturing in the same implementation. While Discrete manufacturing allows multiple segments, OPM allows only a single segment for item code. Most of the time a single user handles both discrete and process inventory. In this scenario, it is better to go in for single segment for both discrete and process inventory.
10. Use numbers instead of alphabets while coding the inventory.
This is important especially if you have a large inventory master. Numeric coding will ensure faster data access enabling faster query fetch and report output. This is related to the internal characteristics of most of the databases currently available.
11. Keep it simple
And finally keep your inventory coding optimal, intutive and as close as possible to the way in which inventory is presently created in the organization. This will ensure quicker training and widespread acceptability to the ERP implementation.

Conclusion
----------
Along with realistic design of Chart of Accounts, the appropriate coding of inventory items is one of the key parameters which decide on the success of an ERP implementation. Properly coded inventory can reap windfall benefits to the organization in providing accurate real time inventory data to the organization. The potential benefits to the organization include accurate profitability data, increased inventory turnover, quick ratio matching current ratio, increase in cash flow and decrease in inventory carrying cost. Moreover inventory optimization helps in debottlenecking of the production flow, freeing up additional space and optimum production and capacity planning exercise.
Considering all the significant expected benefits, it is very important for the organization to devote superior talent, planning and time to the exercise of inventory coding. Following the above guidelines can go a long way in ensuring minimal surprises while undertaking the above exercise.

Deriving benefits from ERP

2007-05-02T10:51:00.000+05:30

According to the "ERP in Manufacturing Benchmark Report" published by the Aberdeen Group, the companies that implemented ERP can be grouped under three different categories - laggards, Industry Average and Best In Class- based on their scores in 4 different criteria vis. Process (what business value has been gained from ERP), Organization (corporate focus / philosophy, level of collaboration among stakeholders), Knowledge (visibility across manufacturing and order fullfillment process) and Technology (scope of ERP implementation and use of technology)
Process: While laggards do not measure any business benefits from ERP, the best in class not only document and continually measure the business benefits, they also update / tighten the business benefits as they achieve one milestone.
Organization: While IT department owns and drives ERP in case of laggards, it is the business that owns the ERP implementation in case of BIC customers
Knowledge: Best in class implementations provide real time visibility to the manufacturing and order fulfillment process.
Technology: While laggards implement only a few of the available modules and use less than 50% of the functionality of these modules, the best in class implementation implement advanced modules like workflow technology , event management etc and utilize more than 70% of the functionality in the implemented modules. Moreover, the best in class implementation are quick to imbibe latest technologies including SOA and other integration technologies.

Any comments?
You can download the report free at Aberdeen Site. You have to register before downloading.

Importance of UAT in an ERP implementation

2007-05-01T12:25:00.000+05:30

UAT (User Acceptance Testing) is a very important milestone in any ERP implementation. A successful UAT can instill initial confidence in an end user since this phase can ensure that all his key requirements are given due consideration in the implementation. For many of the end users, this phase is his / her introduction to the ERP implementation which in some ways is going to significantly change the way he is going to work!!.
Unfortunately it is also true that UAT is not given the due seriousness it deserves in many implementations. Most of the time, UAT period is considered to be a 'buffer' which can be used in case of time overruns in the earlier phases. The lack of seriousness in UAT can manifest in many ways including hastily prepared test scripts, poorly created test plan, absense of test strategy, insufficient pre UAT communication to the end users, last minute identification of the end user to do the testing.... I can go on.
Why is it that UAT gets very little importance in many implementations. One reason is the time pressure. The go live date has been widely publicised in the top management and the project has had serious time overruns as it approaches UAT. The pressure to meet the 'go live' deadline is so high that implementation succumbs to the pressure to compromise on UAT.
Second reason is that since UAT is the introduction to ERP for the end user, the tendency to make it appear to be successful to the user is very high. So the test plan is prepared with all the generic straightforward scenarios which have been tested thoroughly. This leaves all the complex, one off scenarios to be enterd in the system only post go live and this leads to user dissatisfaction in that phase. Another problem with this approach is that the key users of the organization who have to stabilize the ERP post go live do not have experience in handling these complex issues since they have not been tested previously!
Third serious issue with the way UAT is conducted is that it test only the modules and not the processes or flow. For example the plan for the PO user will contain items like entering PO, doing a material receipt, checking the inventory to see if item quantity has correctly increased etc. And for a payables user the testing will consist of entering invoices, making payments, checking accounting etc. Logically the UAT should test the Procure to pay cycle by following the same PO to its payments and the impact in GL. This seldom happens.
In addition to the point mentioned above, there are other issues as to why less focus is given to UAT. It will be a good idea to have the involvement of an external consultant to ensure the success of ERP. In this context the following article by Venkat Manthripragada in IT Toolbox provides 10 reasons why involving an external consultant during UAT is a good idea. Some of the reasons he mentions include providing perspectives, completeness of test scenarios, expertise etc.
Check this out.
Can you think of other reasons why UAT tend get a short shrift during an ERP implementation? And various ways in which this lack of seriousness manifests itself?
Your comments are welcome.

Key expected business benefits from an ERP implementation

2007-04-30T16:11:00.000+05:30

"ERP in manufacturing benchmark report" published by Abardeen Group has thrown up many interesting insights into superior ERP implementations. According to the report, one of the key success factors in ERP implementation is the clear identification of expected business benefits post ERP. Some of the benefits that an organization can expect post ERP implementation are:

1. Streamline business processes
2. Automation of manual processes
3. Visibility provided to the business
4. Cost of software and services
5. Length of time to initial 'Go Live'
6. ROI
7. Length of time for full implementation
8. Process cost savings
9. Ability to meet compliance requirements
10.Ability to connect with customers and suppliers

In addition to the above, in my opinion, the organizaition should also look at the following matrics.
1. Length of time to stabilize: I have seen complex implementations stabilizing in 3 months and simple implementations stabilizing in anywhere between 2-3 years. 3-6 months is a reasonable benchmark I think.
2. Time to close period: I have implemented solutions which brought down the period closing time from 15 days to 3 days. 3 days is a good benchmark, I feel. However this will also depend on the complexity of transactions esp. inventory transactions.
3. Reduction in customer / supplier disputes: Though it is difficult to put a definite number on this matric, ERP implementation should progressively reduce the disputes to 20-25% of the current figures in a span of 6 months approximately.
4. Increase in inventory turns
5. Decrease in ACP: Directly related to reduction in customer disputes.
6. Visibility and accuracy of inventory and consumption figures: In one of the implementations, the consumption figure accuracy increased from 70% to 98% thereby enabling more accurate profitability figures.

These are some of the matrices that can be used to assess the benefits of ERP implementation. Are there any other matrices that you are using in your implementations?

Please let me have your comments.

Why do ERP implementations fail?

2007-04-27T10:51:00.000+05:30

I work as an ERP implementation consultant with a large IT firm here in India. In the last 5 years I have had experience in implementing and participating in over 9 implementations. I have worked on both small ERP packages (Scala) as well as Large Packages like Oracle Applications. There is no doubt that ERPs add value to the organization if properly implemented. As you can see the key phrase is 'Properly implemented'. This is a rare case esp. in case of large packages. There are many reasons touted for this. My view is that the following are the key reasons for failure of many implementaions.
1. The package philosophy: Packages like Scala are designed keeping the end user in mind. So it has built in flexibility to handle any kind of user requirements. But packages like oracle follows a top down approach and focus on top management requirements rather than the requirements of the user. One result is that many of user requirements are not met. This leads to excessive customization.
2. Module specialization: Large packages follow a module specialization approach and hence you have multiple consultants implementing the different modules. This requires consultants who are aware of the overall picture of the implementation and has knowledge of the detailed flows. Such consultants are rare to find. It is infact surprising that the ERP packages which aim to integrate the operations of the organization create module 'silos' at the time of implementation. This is more than a Project Management issue. This is an implementation philosophy issue.

Any other broder level issues you can identify that prevents proper implementation of ERP? How do you handle them? Feel free to comment on this.

7 Flows to be considered in an ERP implementation

2007-04-26T20:50:00.000+05:30

Introduction

A functional consultant going to implement an ERP solution need to have a clear and structured idea of the various aspects of the business. An ERP implementation can be successful only if it is done top down. This means that the consultant has to identify the business issues and constraint before he gets down to the task of designing the solution. One way to do this is to start with the key reports that the organization is presently using and analyse as to the kind of information that is key to this organization.

To understand the business in a structured way, one of the methods is to divide the business into various flows. There are 7 important flows that a consultant need to understand thoroughly and integrate the same in the ERP to ensure a successful ERP implementation.

1. Business Flow:

Logically business flow encompasses all the processes being presently followed by the organization. However, from the perspective of ERP implementation, the consultant has to focus on certain key questions to understand the business thoroughly. Some the questions which should be used in this analysis are;

Where does organization procures materials? What are the key specs. What are the top three raw materials? How many supplier per item on an average? What is the relationship dynamics between supplier and organization? who is more powerful ? What are the three key issues in procurement where you can add value.
What is the organizations conversion process? How efficient is internal processes? How is the production planning done? How is inventory management done? What is the inventory turnover ratio? What is the level of obsolete inventory in the organization? How is the quality measured? How is the material being managed? what is the costing method used? Why are they using that costing method? How complex is the routing? Do they use subassemblies in manufacturing? Are their local taxes? how is excise handled?
How does organization get the customer orders? How are the customer entering the organization? Are there many one time customers? How does order gets registered? How does orgn handle available to promise issues? how is the material movement handled? What is the cost of items? How general are the items? can we divide the items into distinct categories? How is the material issue taking place? How does the costing gets done? How does the organization measure the profitability? Is it on a per order basis or a per customer basis? Do they follow significant customer approach? Do they have separate priority for category 1 customers and another for the other types of customers? What is the criteria for deciding a customer as a category 1 customer? How frequent is the reviewWhat is the size of inventory master? How are items coded? How is costing done? What is the costing method used? Why?What is the nature of the organization? Is it distribution intensive? Does it have many depots? Franchises? Is it operations intensive? Is it purchase intensive?
What is the power structure in the organization? Who is the project champion? Who could be a potential risk? what is the age profile? What is the change culture of the organization? Are they comfortable with technology? Are they going to ERP for clearly identified business benefits or are they going because competitors have moved into ERP? Is business leading the ERP implementation or is it considered as just another IT project in the organization?
At the end of business flow understanding, you should have a clear idea of top 3 business reasons why the organization is going for and ERP and the key reasons for chosing this particular ERP package. This would give you a clear idea of what is expected out of this implementation. Answer to the last question could give you a clear idea of the risks involved in this implementation.

2. Proces Flow:
Here we are talking of various business cycles. You need to know the P2P, Production and O2C cycles with some level of detail with the accounting impact. This will decide some of the key setups

3. Material Flow:
How does the material come into the organization? How is it accepted into inventory? What is the role of inspection? What is the matching process? How is the material moving in to production? Is it in bulk or based on each production order? How does the material come back into Raw material warehouse? How does it come into FG stores? How is it picked for shipping? How it it packed? Shipped?This will give you a clear picture of the complexity in inventory handling process.

4. Document Flow:
For each of the flows discussed in step 2 and 3, you need to know the associated document flows. Some of these documents are internal to the organization (inspection report, GRN etc) where data accuracy is of primary importance, while others are external to organization (PO, AR Invoice etc) where data accuracy as well as formatting are equally important. The consultant should focus more on external reports without spending too much time on the look and feel of internal reports.
For example, in a P2P (Procure to Pay) process, the document flow could be indent (requisition) --> Quotation --> PO --> Inspection report -->GRN (Goods Received Note) --> Delivery Challan --> Invoice --> Payment Voucher

5. Accounting Flow:
For each of the processes discussed in point 2, you need to know how the Accounting entries are generated and how they impact the profit / profitability of the organization. Please note that for every inventory transaction ERP creates an accounting entry (Perpetual inventory valuation). you need to be clear of the accounting steps. The inventory accounting has a tendency of getting out of hand. One of the key constraints in ERP is the understanding of local tax accounting flows and mapping the same. The consultant need to allocate some time for this activity.

6. Report Flow:
You need to know the key reports in the ERP package which shows that all the above flows are functioning correctly. Some of the reports key reports are Inventory valuation report, Open invoices report in both AR and AP, Supplier advances in AP, Customer Advances in AR, Assets Register, Depreciation / Accumulated Depreciation report, Supplier listing, Customer listing, Open POs, Open SOs, Trial Balance etc.

The above 6 Flows are what is defined as 'Above the Surface' Flows. A functional consultant need to be clear of the above flows.

7. Data Flow:
How the data flows through the database based on your transactions. What are the key tables? What are their linkages? How does the data flows from one process to another?

A consultant should at the beginning of the project strive to attain a clear understanding of the above flows. This will help him to talk the language of the organization which is very important from the perspective of the end user, to tailor his implementation to the business requirements of the organization and have a clear assessment of the implementation risks.