0. Introduction to This Blog.
0.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.
0.2. Rhetorical Style of This Blog
When I was working toward my PhD in Linguistics at NYU (left incomplete as an ABD), 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.
0.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.)
1. Legacy ERP Transformations: Three Types of Conflict Therein
As shown in Figure 2:
any Legacy ERP Conversion (LERCON) can be viewed as an effort in three very different dimensions:
- a functional dimension in which, for example, the generic processes of business re-engineering and the SAP-specific process of blueprinting are undertaken;
- a technical dimension in which business re-engineering and blueprinting decisions are transformed into technical actualities, via, for example, the technical processes of data ETL (extract/transform/load), the addition of data and process objects to customer namespaces, etc.;
- a socio-political dimension in which decisions are made as to how to structure, staff, and manage efforts in the other two dimensions.
In all three of these dimensions, conflict is rife; it is the norm; it is the nature of the beast.
As such, it can only be disregarded or hand-waved at the peril of the LERCON itself.
1.1. Socio-political Conflict.
Figure 3 portrays one possible framework in which to discuss sociopolitical conflict within a LERCON:
The grid in this figure "slots" the various "actors" in a LERCON against the various "organizations" to which these actors belong. For example, "management actors" can be found in any of the organizations participating in the LERCON: the prime (systems integrator) and its sub(contractor)s; the ERP vendor (ideally, SAP), facilitating vendors (e.g. those who provide ETL or messaging software), and of course, the client (customer) organization(s).
Within this grid, one potential "polygon of conflict" is shown among three kinds of actors: a)business re-engineers working for the prime or one or more of its sub(s); b) client functionals (the domain or subject-matter experts provided to the LERCON by the client); c) functionals provided by the ERP vendor itself (e.g. to argue that a given piece of vendor functionality need not be modified, i.e. that it is the client who must adapt to "best practices" as defined by the vendor.)
With respect to any polygon of conflict within the socio-political dimension, it is extremely important to note that such conflicts are never substantive - they are only organizational and procedural conflicts arising from such questions as:
- who has the final word ?
- who has access to project management ?
- who is privy to what information ?
- etc.
To say that socio-political conflicts are never substantive is not, of course, to say that they are not important. They are critically important, and that is why some model for "doing" LERCON's is desperately needed.
In the presence of a generally accepted model for "doing" LERCON's, socio-political conflict cannot arise. All issues are resolved up-front by the model, and by the agreement of all parties to operate within this model which they have agreed upon.
Yes - for a certain type of LERCON "actor" with whom we all are all too familiar, a generally-accepted model for "doing" LERCON's will "take all the fun out of it."
That's exactly what this blog is about.
1.2 Functional Conflict.
Figure 4 shows one version of a familiar grid to which all functional conflict arising in a LERCON can be referred:
This figure needs little exegesis; the vendor and the client will differ on what is required, optional, unnecessary, and missing from their naturally different points of view.
Hence, vendor-client functional conflicts arise as principled conflagrations to which unprincipled fuel is too often added by LERCON actors outside the vendor and client organizations: managers, functionals, and business re-engineers from the prime and/or its subs.
That's another thing this blog is about.
1.3 Technical Conflict.
Figure 5 shows a grid to which all technical conflict arising in a LERCON can be referred:
All experienced readers of this post will be familiar with technical conflict over persistent data. The issue here is not the trivial one of whether some client data-item(s) match(es) some vendor data-item(s). The issue is whether the vendor data are intrinsically organized to optimize the achievement of agreed-upon functionality, or whether this organization must be supplemented by auxiliary cross-references, etc.
Same with transient data. Does the vendor software and any agreed-upon external messaging software provide the necessary means for data transfer in ways that satisfy not only external criteria of efficiency, but also internal operational constraints on client activities.
Same with core processes. Does the vendor's event management of core processes jibe with the client's notion of how core process events should be managed ? E.g.: optionality of EOD/EOW/EOM/EOQ/EOY processes ? Recoveries from failures in core-processes?
Interfaces! Ah-ha! The great "gotcha".
And therefore, the most frequently over-looked and hand-waved gotcha.
It's the gotcha that got me into this aspect of the IT business.
It's also what this blog is really all about, in the final analysis.
Cause this blog really doesn't need to be read by anyone involved in a LERCON which requires no interfaces.
0.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.
0.2. Rhetorical Style of This Blog
When I was working toward my PhD in Linguistics at NYU (left incomplete as an ABD), 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.
0.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.)
1. Legacy ERP Transformations: Three Types of Conflict Therein
As shown in Figure 2:
any Legacy ERP Conversion (LERCON) can be viewed as an effort in three very different dimensions:
- a functional dimension in which, for example, the generic processes of business re-engineering and the SAP-specific process of blueprinting are undertaken;
- a technical dimension in which business re-engineering and blueprinting decisions are transformed into technical actualities, via, for example, the technical processes of data ETL (extract/transform/load), the addition of data and process objects to customer namespaces, etc.;
- a socio-political dimension in which decisions are made as to how to structure, staff, and manage efforts in the other two dimensions.
In all three of these dimensions, conflict is rife; it is the norm; it is the nature of the beast.
As such, it can only be disregarded or hand-waved at the peril of the LERCON itself.
1.1. Socio-political Conflict.
Figure 3 portrays one possible framework in which to discuss sociopolitical conflict within a LERCON:
The grid in this figure "slots" the various "actors" in a LERCON against the various "organizations" to which these actors belong. For example, "management actors" can be found in any of the organizations participating in the LERCON: the prime (systems integrator) and its sub(contractor)s; the ERP vendor (ideally, SAP), facilitating vendors (e.g. those who provide ETL or messaging software), and of course, the client (customer) organization(s).
Within this grid, one potential "polygon of conflict" is shown among three kinds of actors: a)business re-engineers working for the prime or one or more of its sub(s); b) client functionals (the domain or subject-matter experts provided to the LERCON by the client); c) functionals provided by the ERP vendor itself (e.g. to argue that a given piece of vendor functionality need not be modified, i.e. that it is the client who must adapt to "best practices" as defined by the vendor.)
With respect to any polygon of conflict within the socio-political dimension, it is extremely important to note that such conflicts are never substantive - they are only organizational and procedural conflicts arising from such questions as:
- who has the final word ?
- who has access to project management ?
- who is privy to what information ?
- etc.
To say that socio-political conflicts are never substantive is not, of course, to say that they are not important. They are critically important, and that is why some model for "doing" LERCON's is desperately needed.
In the presence of a generally accepted model for "doing" LERCON's, socio-political conflict cannot arise. All issues are resolved up-front by the model, and by the agreement of all parties to operate within this model which they have agreed upon.
Yes - for a certain type of LERCON "actor" with whom we all are all too familiar, a generally-accepted model for "doing" LERCON's will "take all the fun out of it."
That's exactly what this blog is about.
1.2 Functional Conflict.
Figure 4 shows one version of a familiar grid to which all functional conflict arising in a LERCON can be referred:
This figure needs little exegesis; the vendor and the client will differ on what is required, optional, unnecessary, and missing from their naturally different points of view.
Hence, vendor-client functional conflicts arise as principled conflagrations to which unprincipled fuel is too often added by LERCON actors outside the vendor and client organizations: managers, functionals, and business re-engineers from the prime and/or its subs.
That's another thing this blog is about.
1.3 Technical Conflict.
Figure 5 shows a grid to which all technical conflict arising in a LERCON can be referred:
All experienced readers of this post will be familiar with technical conflict over persistent data. The issue here is not the trivial one of whether some client data-item(s) match(es) some vendor data-item(s). The issue is whether the vendor data are intrinsically organized to optimize the achievement of agreed-upon functionality, or whether this organization must be supplemented by auxiliary cross-references, etc.
Same with transient data. Does the vendor software and any agreed-upon external messaging software provide the necessary means for data transfer in ways that satisfy not only external criteria of efficiency, but also internal operational constraints on client activities.
Same with core processes. Does the vendor's event management of core processes jibe with the client's notion of how core process events should be managed ? E.g.: optionality of EOD/EOW/EOM/EOQ/EOY processes ? Recoveries from failures in core-processes?
Interfaces! Ah-ha! The great "gotcha".
And therefore, the most frequently over-looked and hand-waved gotcha.
It's the gotcha that got me into this aspect of the IT business.
It's also what this blog is really all about, in the final analysis.
Cause this blog really doesn't need to be read by anyone involved in a LERCON which requires no interfaces.
1 Comment
