Skip to Content
In the previous sections of this blog: The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 12) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 11) The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 10) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 9) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 8) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 7) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 6) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 5) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 4) The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 3) I’ve been talking about the basic payoff of a DMDR (Diachronic Metadata Repository). This basic payoff is summarized as best as I can in the top-half of Figure 20. (Yes – I know I don’t summarize all that well.) Figure 20 image But as the bottom-half of Figure 20 should make clear, there are three additional value-added payoffs which derive from using a DMDR to structure, organize, and govern a LERCON (Legacy -> ERP conversion.) Easy Generation of Accurate Management Metrics The first of these value-added payoffs – easy generation of accurate management metrics – is characterized in Figure 21: Figure 21 image As this figure shows, the OLAP infrastructure to support LERCON management progress metrics is readily obtainable from the basic MAP infrastructure which project analysts use as they build (or auto-generate) their mappings from AsIs Function, Process, and Data to ToBe Function, Process, and Data. Either an AsIs Function has been mapped to a ToBe Function (perhaps null) or it hasn’t. Either An AsIs Process has been mapped to a ToBe process (perhaps null) or it hasn’t. Either an AsIs data element has been mapped to a ToBe element (perhaps null) or it hasn’t. The point is this: If LERCON management insists that all project analysts store their hand-built and generated mappings inside one central DMDR, and also that this DMDR be the “database of record” for what has and hasn’t been done, then it becomes very very difficult for project analysts to “fudge” their status reports. Reusability of Effort: (WYD)**2 Training The second value-added payoff mentioned on Figure 20 is re-usability of effort when it comes time to generate ToBe training materials. As shown in Figure 22: Figure 22 image LERCON training materials should ideally include a web-based application which lets any customer staff-member easily see exactly what will be the ToBe equivalent(s) for each Legacy report or screen that he or she is used to working with. And it is really quite impossible to create such correlated displays of “what you did/what you’ll do” unless the properties of the AsIs and ToBe systems are pre-correlated in the mappings of a DMDR. Reusability of Effort: Trouble Ticket Routing Same thing goes for transitioning your help desk from support of the AsIs environment to support of the ToBe environment (see Figure 23). Figure 23 image Generally speaking, when a ToBe process yields the wrong result after conversion, it’s going to take three kinds of technical staff to diagnose and solve the problem: (i)staff familiar with the AsIS process(es) corresponding to the ToBe process, (ii) staff familiar with any aspects of data migration and on-going interfaces relevant to the ToBe process, and (iii) staff familiar with the ToBe process itself. So why not pre-position resource combo’s for any potential problem that may arise during or after your LERCON, using the AsIs -> ToBe mappings of a DMDR to tell you exactly how these resource combo’s must be put together? Or would you rather scramble at the last minute to figure out who and what you need to make sure your pager stops beeping at 2 in the morning?

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply