When the SAP marketing guy promises this and that, be forewarned that what is promised might not be what you're gonna get after implementation.
This is the main culprit for every implementation headache. The marketing guy will say this and that, but in actuality it's different in SAP.
For example, they will say BW can produce report with a "single-click of a button and it's very flexible". But when comes to implementation, we know better that it's not the way things work.
Why? Well to produce a report there's a whole chain of process that needs to be done in BW to support that reporting. To add even one field for reporting, will require changing various steps, from transfer structure, to communication structure, to even the data target level (infocubes and such).
See. Not that flexible eh? Well to all the marketing guy, next time, please do not promise something that you know the technical team cannot deliver. Set the user expectation right from the start. Saves a lot of headache and "RESCOPING" later.
Friday, October 28, 2005
3
Thursday, October 20, 2005
0
A moment of silence.
Deepest condolence to our PM Pak Lah for the passing of our First Lady Datin Seri Endon Mahmood. Al-Fatihah.
Yep, most Malaysian News Portal have been jammed by massive http requests as of now.
Yep, most Malaysian News Portal have been jammed by massive http requests as of now.
Monday, October 17, 2005
0
Migration. How to get an SAP migraine!
Yes ladies and gentlemen. There is such a "pain in the ass" in the SAP world. And you will only feel the full blown of pain during data migration.
Why? Because most likely, your users will want to migrate all the historical data that they have in their previous legacy system. Hell, they might even want you to migrate all the manual documents since the company was formed!
But guess what, the general guidelines for an SAP legacy migration is "open item" and "balances" only. What does this mean? Well, let's say you have an invoice that has not been completed yet, so all data in the legacy system pertaining to this invoice is considered an open item. What about all the completed ones? That my friend, won't be migrated to SAP.
This statement alone will invoke the fury of the users. Why such limitation? Why do we have to irritate the users with this statement? The reason is due to the integrated nature of SAP. If you wanted to migrate the information about the invoice, most likely you need to feed some other information that won't be available in the legacy system in the first place. Therefore, migration of that completed invoice doesn't make sense.
So, in one hand you have the users who will pressure you to migrate all historical data available. And yes, they will make all sort of justification (including but not limited to "legal or statutory requirement"). And in the other, you have the "SAP guidelines" for a hassle-free implementation and no data-integrity issues.
My advise: Thread wisely.
Why? Because most likely, your users will want to migrate all the historical data that they have in their previous legacy system. Hell, they might even want you to migrate all the manual documents since the company was formed!
But guess what, the general guidelines for an SAP legacy migration is "open item" and "balances" only. What does this mean? Well, let's say you have an invoice that has not been completed yet, so all data in the legacy system pertaining to this invoice is considered an open item. What about all the completed ones? That my friend, won't be migrated to SAP.
This statement alone will invoke the fury of the users. Why such limitation? Why do we have to irritate the users with this statement? The reason is due to the integrated nature of SAP. If you wanted to migrate the information about the invoice, most likely you need to feed some other information that won't be available in the legacy system in the first place. Therefore, migration of that completed invoice doesn't make sense.
So, in one hand you have the users who will pressure you to migrate all historical data available. And yes, they will make all sort of justification (including but not limited to "legal or statutory requirement"). And in the other, you have the "SAP guidelines" for a hassle-free implementation and no data-integrity issues.
My advise: Thread wisely.
Sunday, October 09, 2005
0
The Holy Grail of SAP
If there is such a thing as a holy grail in SAP, then I think it would be the the Charts of Account (CoA). This chart of accounts will determine the structure of the financial elements of the SAP implementation and this will chain-react to the other SAP modules.
So, what the heck is CoA? CoA is like a big animal. Simply put, it's a list of accounts to be used in a company. This CoA has a few elements in it to bring meaning to the financial accounts.
An example of the elements of a CoA is:
So, what the heck is CoA? CoA is like a big animal. Simply put, it's a list of accounts to be used in a company. This CoA has a few elements in it to bring meaning to the financial accounts.
An example of the elements of a CoA is:
- GL Account No - Simple number of a General Ledger (GL) account
- Cost/Profit Center - An organizational unit that's a sales dog (profit center) or just a big spender (cost center)
- Yada yada yada (too mouthful to mention)
All these elements will define the CoA. So, any GL entry, should have part or all of these information to make a really good posting. Thus, a good CoA, will make financial analysis a breeze. Things like Profitability Analysis, Cost Analysis will become much much more meaningful.
So, what happens if suddenly some tom,dick or harry decided to change the CoA in a middle of an SAP implementation? All hell break lose!!! I pity those SAP consultant who's in that kind of situation.