In the previous sections of this blog: The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention Durin... The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention Durin... The Diachronic Metadata Repository (DMDR) as a Tool for Risk Reduction via Conflict-Prevention Durin... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legac... 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 
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 
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 
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 
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?
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 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 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 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?