| Key 7: One System of Records per Function |
|
|
| Written by Berthold Kastel | ||||
Page 2 of 2
As a practical application this means that there always should be only one system of record per transaction and kind of data. For example, WBS elements should only be created and updated in SAP, activities may be originally created in SAP but then updated in a third party system, high level budget data will be maintained in SAP and are standard cost rates - but not the planned or actual hours that are being multiplied with such rates to become the basis for detailed cost plans.
In this context it is counterproductive to use an integration application that saves data from various sources and applies algorithms to figure out when to update what system. The "clearing data base" will then act like a data warehouse, except that it is an operational one. If before two systems (and one relationship) needed to be kept in synch, now it is three systems (and three relationships!). The task of ensuring data consistency just became much harder.
Copyright © 2007 Competitive Edge International, Inc. |
||||
| < Prev | Next > |
|---|
| Polls |
|---|
| Related Items |
|---|





