Skip to Content
In The Diachronic Metadata Repository as a Tool for Risk Reduction via Conflict-Prevention During Legacy-to-ERP Conversions (Part 3) of this blog, it was argued that: (I) In order for a Legacy-to-ERP Conversion (LERCON) to proceed with the least risk and greatest chance of success, it must be driven by a consensual process-model based on a Diachronic Metadata Repository (DMDR) with a structure like this: Figure 11 image (II) The LERCON should not proceed until the “AsIS” and “ToBe” Business Function cells of the DMDR are implemented as two relational tables linked by an intersection table: Figure 11c image (III) The LERCON should not proceed until the DMDR is front-ended by a web-based application which permits all LERCON actors to see: i) the units of AsIs business functionality deemed relevant to the LERCON; ii) the units of ToBe business functionality deemed relevant to the LERCON; iii) how business analysts/process experts/re-engineers have related specific units of AsIs business functionality to specific units of ToBe business functionality. But with respect to (I-III), it is important to note that I’m NOT suggesting that no other LERCON-related work can or should be done until a mapping between AsIs and ToBe business functionality has been completed and made available for inspection via a web-based application. To the contrary – a DMDR with a structure like that shown in Figure 11 has two other horizontal components apart from a Business Function component: an IT Process component and a Data component And while the business analysts, re-engineers, and process experts are busy building the Business Function component of the DMDR, the real knowledge workers can also be busy building these two components as well. Like the Business Function component of a DMDR, the IT Process component of a DMDR can be represented as two relational tables plus an intersection table, as shown in Figure 11d: Figure 11d image But unlike the intersection table in the Business Component of the DMDR (see Figure 11c), the intersection table in the IT Process component is not filled in “by human hands”. While the intersection table in the Business Function component is filled in by business process experts, business analysts, and business re-engineers who map units of AsIslegacy business functionality to units of ToBe SAP functionality, the intersection table in the IT Process component gets completed by the DMDR itself. How can that be? How can the DMDR be smart enough to fill in the IT Process intersection table without any assistance from human experts? The answer to this question is simple: the DMDR fills in the IT Process intersection table using two other intersection tables that are filled in by human experts, as shown in Figures 11e: Figure 11e image In particular, the three “1’s” in Figure 11e indicate that two additional analytic processes can be carried out simultaneously while the business analysts, business process experts, and business re-engineers are busy building the AsIs<>ToBe Business Function intersection table. First, AsIs legacy experts can be busy building an intersection table between AsIs Business Function and AsIs IT Process. (It is amazing how many large large private and public sector entities continue to operate without ever having constructed such an intersection table – it is even more amazing that these entities think they can pull off a LERCON without one.) Second, ToBe SAP experts can be busy reverse engineering SAP’s metadata tools so thay they can be used to build an intersection table between ToBe Business Function and ToBe IT Process. (My team actually did this three or four years ago, so I know it can be done – the only interesting question is why SAP makes it so difficult to build this intersection table, when no LERCON can really do without one.) And lo and behold – once all three of these intersection tables have been built within the DMDR: the AsIs<->ToBe Business Function intersection table the AsIs Business Function<->IT Process interseection table the ToBe Business Function<-> IT Process intersection table the DMDR can use these three tables to automatically compute an AsIs<->ToBe IT Process intersection table that will be far more accurate than any version of this table constructed “by human hands”. ***** This blog is now only one post away from being able to show why construction of a DMDR is even more critical to a LERCON that is being undertaken by a private or public sector entity which is interested in taking advantage of SAP’s ESOA offerings. But discussion of this point will have to wait until something has been said about the Data component of the DMDR.

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