|
Experiences -
Lessons Learned
|
|
Written by Marc de Kam
|
|
Thursday, 15 January 2009 16:26 |
|
Some organized and unorganized thoughts after implementing FSAH within a medium-sized european telco.
Approach
Think about phases.
A FSAH-platform is not implemented for connecting just one application. So part of the strategy is to identify the set of applications to be connected and to rank them. Ranking should be based on several criteria.
- Amount of manual effort needed to feed GL manually. Obviously the higher the number of FTE monthly involved in this, the more urgent a connection via FSAH.
- Resource capacity with knowledge on accounting. Often knowledge on the ins and outs of accounting for specific product or specific business lines is scarce. People with this knowledge are needed in their operational role (especially during period close). Simultaneously connecting two or more legacy applications which require the specific knowledge of one person is not a good idea.
- Lifecycle-phase of legacy application. The older the legacy application is, the fewer people with knowledge on that application will be around. This may mean a choice between quick-and-dirty connecting the application using existing output (and thus maximizing roi for the time remaining) and leaving the application for what it is (and maintain the current manual processing).
Outcome of the ranking could be a programme for connecting 3 to 4 applications to the accounting hub with a 3 to 4 month heartbeat.
Process events or not...
The ideal is to translate events into journal entries. The fact is that many legacy systems when they were initially implemented had some kind of accounting function built in them. They produce not only events but often also produce some kind of gl reports.
Per legacy application can be decided whether you go to event-based interfacing in one step or leave the accounting function of the legacy application for now intact and let the accounting hub process the current output from the legacy application. This has several advantages:
- The organization is already prepared for the change in process: Maintenance of the company accounting rules move from decentralised departments to a central department.
- No need for managing two teams that both have to change their interfacing with including all timing issues.
The disadvantage is that you may have to change the interfacing at a later stage, which is in the end less efficiënt. Many times legacy applications do not have such a long life cycle anymore. In that case you do not have this disavantage, but do have the benefits of centrally controlled accounting.
Keyuser involvement
Keyusers are normally involved in the reviewprocess and later on in an acceptance-test role. New accounting rules are drawn up as accounting requirements in the design phase. A conference room pilot should not only demonstrate the fact that the new platform works. It should also demonstrate that the new way of accounting is in line with accounting of the old platform. Also bear in mind that for keyuser involvement, there are different audiences to be considered. Financial control, Accounting (shared service center) and the administrative organization department each have there own inputs.
Configuration of FSAH
Within a FSAH Application you have an enormous freedom in defining events, journal line types and account derivation rules. A balance must be found between defining very little (maximum re-use, not much to maintain, strong analytical thinking necessary) and defining everything (more setup and maintenance needed, quicker insight and less confusion on how accounting takes place). I found that having a journal line type for every line type in an event type is useful. This means that you have more line types than actually needed. You only need to link them to an event class. But it helps problem solving and isolates impact of changes. When you follow this strategy you should try to minimize the number of account derivation rules.
Subledger guiding principle
Try to have a strategy on subledgers before starting the first pilot. Sometimes different applications may be grouped and seen a single source in GL. If Accounting agrees to this, the result could be that a lot less setup is necessary. The same applies to a strategy on eventclass/journal category.
Decision model
- How important is it to see journal entries in GL from 1 source system together?
- How important is it to see journal entries in GL from 1 event class (spread over more sourcesystems) together?
- What prevails?
Example:
| Accounting Hub |
General Ledger |
Option 1 |
Option 2 |
Option 3 |
| Application |
Journal Source |
Billing |
Billing |
Billing System 1 |
| Entity |
|
Billing System1
Billing System2
Billing System3 |
Billing System1
Billing System2
Billing System3 |
Billing System1 |
| Event Class |
Journal Category |
BS1_Billed
BS2_Billed
BS3_Billed
BS1_Unbilled
BS2_Unbilled
BS3_Unbilled
|
Billing System1 |
Billed / Unbilled |
| Event Type |
|
XXX_Earned
XXX_Unearned
XXX_Accrued
|
Billed earned
Billed unearned
Unbilled earned |
Earned / Unearned |
Development phase
FSAH is relatively new. There are some bugs. Which are usually followed up pretty quick. Create Accounting is the key process. When running this process be aware of performance issues. All reports are XML Publisher reports. Be sure to pay attention to scalability and enough space in xml-publisher tmp directory. Mapping sets containing a flexfield as an output value cannot be queried.
Make sure there is a good definition of incoming files and the valueranges used in these files. If not you building your importvalidation and configuration on a moving target. This, of course, is true for all interfacing
Wishlist
Integration FSAH and MasterData-tool!
Mappingset input and output values often involve (financial) masterdata items. Yet there are no tools to synchronize the mappingset outputvalues from a masterdata-system outside Oracle EBS.
Global Consolidation System inadequate?
Cross-version global consolidation functionality is desirable (and should not be that difficult to develop in my opinion). Reason: you can start implementing the accounting hub even when your GL is a pre-12-version. You just put on an extra R12-instance with only FSAH and GL activated. GL12 and GLpre12 can be connected via GCS instead of custom export and import. Also for organizations that have multiple Oracle GL instances (not likely to be on the same version over a longer period of time) GCS would suffice.
|
Comments
The FAH implementation itself does not require a big bang approach either. You can go-live with one source system and connect other source systems at your own pace.
I've just posted a new article on this site with provides information on the FAH setup steps.