Page 102 -

Taking Software Packages into Account 63

the software package does not overlap with the management
of transactional data and reference/master data on the same
screens. Indeed, by neutralizing the data repository user
interface, it is important that this does not cut the software
package off from some transactional management screens. If
the software package is not properly clear on this point, it is
necessary to carry out an analysis of all the screens and
judge the overlap levels between these two data types; or

– admit that the software package remains “master” on
a subset of reference and master data. Therefore, the
operational teams can continue to create certain domains of
reference and master data (example: Articles) in the ERP,
but this data is consolidated in the enterprise MDM system,
undergoes a validation/enrichment life cycle on a much
larger data model, and then is re-synchronized with the
software package.

Other administration functions of a locked MDM system
must be studied in order to decide on any overrides. For
example, the audit functions of data consultation can be
preserved. Similarly, default procedures of repository
safeguard are generally maintained.

3.3. Impact for software vendors

What remains in the scope of software packages once the
reference and master data, their business rules and
processes are externalized into the MDM system, the BRMS
and the BPM, respectively?

Software packages change their nature; they must be
capable of interacting with the three repositories. A software
package’s benefits are then found in the integration between
processes, rules and reference/master data. It retains the
responsibility for transactional data management which, by
definition, is not found under the control of the MDM