Developing a Knowledge Management Strategy 115Copyright © 2005, Idea Group Inc. Copying or distributing in print or electronic forms without writtenrecommendations for transitioning from the “as is” state to the “to be” state, and an
additional section provided an even more in-depth description of recommendations of
what needed to be done to achieve the “to be” state. These assessments with the final
recommendation descriptions are detailed in Appendix 5. On the whole, the assessments
were comprehensive and surfaced many technical and cultural issues that had to be
addressed if AFMC was to transform itself into a true knowledge-sharing organization.
These final reports, however, were not what Adkins had expected the strategic vision and
plan document to be. The recommendations captured the complicated nature of the
current AFMC environment yet, while providing a good road map for the future, were so
broad and involved that it was difficult to determine a starting point. To further compound
his disappointment, Adkins also learned that AeroCorp considered completion of the
assessment reports as having not only fulfilled deliverable #1, the AFKM Strategic
Vision and Plan, but also deliverable #2, the AFKM Integration Recommendations
Document. He was baffled.
Although Adkins had not gotten exactly what he expected from AeroCorp, the
company was allowed to continue work on the remaining deliverables. Adkins hoped that
the subsequent documents would make things clearer. Deliverable #3, the AFKM
Integration Blueprint, which AeroCorp referred to as a KM methodology, took much
longer to produce than the assessments. Delays resulted, first of all, from the turnover
of two AeroCorp program managers during early 2001. The current program manager,
Mike Lipka, though very knowledgeable about KM, was relatively new to AeroCorp and
had to get up to speed on the AFKM project. The key delay, however, stemmed from the
fact that AeroCorp had difficulty developing a concise KM methodology or “blueprint”
that could address the enormity of what AFMC needed to do to develop a comprehensive
KM program that would help it evolve into a true knowledge-sharing organization.
Although the initial assessment and recommendations documents had stated that
a systems engineering approach would be used to design the “integration blueprint,” the
use of integrated definition (IDEF) process modeling methodology surprised Adkins and
Lipka. Neither Adkins, nor his superiors, were familiar with this methodology. Lipka,
having not been the program manager when the decision to use IDEF was made, had not
seen it applied to KM before. Developed for use in systems engineering, IDEF modeling
had been around for quite a few years. Its primary users had been the DoD and other large
organizations. IDEF had originated with the AF’s Integrated Computer Aided Manufac-
turing (ICAM) program in the mid 1970s, but had evolved over the past six or seven years
to also address modeling enterprise and business areas. As such, it was used for
modeling “as is” enterprise processes and defining information requirements for im-
proved planning. On the whole, there were 14 separate methods being developed within
the IDEF family for use in business process engineering and reengineering, software
process definition and improvement, and software development and maintenance areas.
It provided a multitude of viewpoints required to describe business area processes and
software life-cycle processes and activities. As such, it stood that IDEF could be
appropriate for modeling an enterprise approach to KM and subsequent KM systems
development, but it did not appear to be a really usable methodology for the average
customer. After seeing the initial draft of the high-level IDEF model (Figure 6), neither
Adkins nor Lipka were satisfied. Lipka expressed his opinion thus: “I think we have too
much methodology for what we need... I think it’s [been] a little overengineered.”