Skip to Content

1. Introduction to This Blog.

1.1 Purpose.

Because Enterprise Resource Planning (ERP) conversions have typically been guided by the vendor-specific practices of ERP solution providers (e.g. SAP, Oracle), executives managing such conversions in the private, public, and defense sectors have no standard model to help them structure such efforts.

Lessons learned from past efforts at large scale legacy ERP conversions indicate that such transformations can be architected and implemented with least risk if executives possess a diachronic metadata repository (DMR) which can help to ensure successful performance of five key ERP conversion tasks:

– seamless translation of business re-engineering directives into technical specifications for initial data and process migration

– generation of accurate technical specifications for those legacy interfaces which must be honored or created

– generation of automated techniques and metrics for requirements traceability (function, process, and data)

– generation of synchronized “what you did/what you’ll do” (WYD2) syllabi and materials for staff re-training

– generation of guide-books to ensure correct Help Desk assignment of trouble-tickets to appropriate technicians

The first purpose of this blog, therefore, is to show why the notion “diachronic metadata repository” (DMR) COULD provide the theoretical foundation for a standard ERP legacy conversion model which both subsumes and extends SAP’s best conversion practices.

And of course, the second purpose of this blog is to attract comments from readers concerning:

– the adequacy of the DMR construct as a theoretical foundation for a standard ERP legacy conversion model

– the TECHNICAL and WORKFLOW engineering challenges likely to surface in any attempt to instantiate the DMR construct in an actual, real-life, arge-scale ERP legacy conversion effort.

In this regard, it should be noted that the truly difficult challenges in large-scale ERP conversions are never the purely technical engineering challenges.

Rather, they are the WORKFLOW, or “human engineering” challenges which arise from the fact that many different actors with radically different motives and preconceptions must all make common cause in order to ensure success.

If I do my job correctly as the author of this blog, it should become clear that the chief value and purpose of “DMR” technical engineering protocols are simply to define and enable a set of human engineering protocols that will help all of us and all of our managers sleep better at night while we are engaged in large-scale legacy ERP conversion efforts.

1.2. Rhetorical Style of This Blog

When I was working toward my PhD in Linguistics at NYU, my main mentor was a fella named Ray Dougherty, who was as much interested in the rhetoric of scientific argumentation as he was in its contents.

Ray used to tell his students to keep in mind three rhetorical “rules of the road” which he himself had read or heard of:

– “if you make people think they’re thinking, they’ll love you; if you make them really think, they’ll hate you.”

– “if you tell folks you think they’ve made a mistake, they will more than likely not take great offense; if you tell them they are fundamentally misconceived, you will never be forgiven.”

– “when the experts are agreed, the opposite opinion cannot be held to be certain”.

As you can see from these “rules of the road”, my intent in this blog is to be provocative.

But it is not ever to be offensive. I will at all times endeavor to restrain my natural bent toward sarcasm and invective, for a very simple reason.

When discussing aspects of legacy conversion efforts that ARE probably worthy of satire in “Dilbert”, it is simply not necessary to be pungent in tone.

We have all seen great idiocies committed in our technical careers, and it is “preaching to the choir” to point out such idiocies with satire, scorn, and sarcasm.

The real challenge is to come up with some solution-set that will minimize the chance of such idiocies being committed in the future, and to try and gain agreement on the idea that a proposed solution-set is worth a try. And in this effort, satire, scorn, and sarcasm will all just hinder rather than help.

1.3 Acknowledgments.

Most immediately, to Mark Finnern of SAP SDN for approving my application to blog, and to Marilyn Pratt of SAP SDN, who was kind enough to suggest that I try to put some thoughts on legacy ERP conversion efforts out at SDN.

Next, to Ed Farler and Roger Bryson of CSC, for permitting work on the CSC LMP Diachronic Metadata Repository to continue as long as they could.

Next, to Dave Korn of Oracle and Dave Donovan (formerly of SeeBeyond) for their initial faith in and encouragement of the Diachronic Metadata Repository construct.

Next, to Randy Cash (SAIC CST Business Unit manager), Wayne Goff (SAIC CST Business Unit Manager), and Rick Woodall (SAIC CST Business Unit Division Manager), for their decision to build a Diachronic Metadata Repository team and keep it extant as long as they could.

Finally, to Dave Bragg (consultant to CSC) and Bill Mann (now with Lockheed-Martin). Dave programmed a prototype web-portal Diachronic Metadata Repository for CSC and Bill implemented the deep technical infrastructure of this DMR in Perl and UNIX, including parses of USArmy Data Management Routine CCSS code (which “they said couldn’t be done” for less than a couple a million.)

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