This article was downloaded by: [Umeå University Library]On: 04 October 2014, At: 04:17Publisher: RoutledgeInforma Ltd Registered in England and Wales Registered Number: 1072954 Registeredoffice: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Journal of Information Technology Caseand Application ResearchPublication details, including instructions for authors and subscriptioninformation:http://www.tandfonline.com/loi/utca20

An Interview with Mrs. Elizabeth StetsonDepartment of Defense in the EnterpriseIntegration AreaConducted and Documented by: Mahesh S. Raisinghaniaa Texas Woman’s University, Texas, USAPublished online: 12 Sep 2014.

To cite this article: Conducted and Documented by: Mahesh S. Raisinghani (2007) An Interview withMrs. Elizabeth Stetson Department of Defense in the Enterprise Integration Area, Journal of InformationTechnology Case and Application Research, 9:3, 49-56, DOI: 10.1080/15228053.2007.10856119

To link to this article: http://dx.doi.org/10.1080/15228053.2007.10856119

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the“Content”) contained in the publications on our platform. However, Taylor & Francis, ouragents, and our licensors make no representations or warranties whatsoever as to theaccuracy, completeness, or suitability for any purpose of the Content. Any opinions andviews expressed in this publication are the opinions and views of the authors, and are notthe views of or endorsed by Taylor & Francis. The accuracy of the Content should not berelied upon and should be independently verified with primary sources of information. Taylorand Francis shall not be liable for any losses, actions, claims, proceedings, demands, costs,expenses, damages, and other liabilities whatsoever or howsoever caused arising directly orindirectly in connection with, in relation to or arising out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any substantialor systematic reproduction, redistribution, reselling, loan, sub-licensing, systematic supply,or distribution in any form to anyone is expressly forbidden. Terms & Conditions of accessand use can be found at http://www.tandfonline.com/page/terms-and-conditions

The Expert Opinion Report

An Interview with

Mrs. Elizabeth Stetson Department of Defense in the Enterprise Integration Area

Conducted and Documented by:

Mahesh S. Raisinghani Texas Woman's University, Texas, USA

Mrs. Elizabeth Stetson works for the Department of Defense in the Enterprise Integration area. She has worked in the business applications/manufacturing field for over 20 years. For approximately eleven years she worked for Hewlett Packard, first as a developer in the semiconductor manufacturing business and later in discrete manufacturing and implementation field. She is certified in Production and Inventory Management. In the 1990s she moved in the Enterprise Resource Planning (ERP) space and in the 1992-1996 timeframe worked in the SAP domain when ERP was taking off in the USA. Mrs. Stetson also worked for an Application Service Provider before going back to work for Hewlett Packard with a focus on high availability technology infrastructure. She also worked for a small startup on business to business supply chain management and pro-services applications.

JITCAR: What is Enterprise Resource Planning (ERP)?

stetson: ERP is a suite of business applications/solutions designed to address all components of an enterprise. It is an outgrowth of Materials Requirement Planning (MRP) I and MRP I1 which were the latest in automation in the 1970s and 1980s. .MRP I was designed to automate materials requirement planning and MRP I1 was designed as a closed loop process from requirements to demand planning where the output from MRP I feeds into the procurement system and links to the sales order system ERP applications reside on a common infrastructure to overcome the application silos such as shop floor order systems and financial applications.

JITCAR: You touched upon proprietary structures ("islands" or silos) that were ubiquitous in the '80s are now posing complexities within current ERP implementations, especially with what you outlined as the 5th component of ERP set-up - that of organizationaVcorporate infrastructure configuration. Are there specific best practices (a replicable framework) in the front-end of the implementation methodology for a standardized costbenefit analysis within a (SAP) ERP configuration plan utilized to determine the true business value of proprietary legacy systems for assessing when and if to hook into or rebuild from scratch a disparate proprietary element?

JITCAR, Volume 9, Number 3, 2007 49

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

Stetson: This is a big question, in more ways than one! First, there are many proprietary methodologies that have been developed, especially by big consulting fums/systems integrators, based on best practices and now a decade plus experience with ERP. These methodologies can be used to do costhenefit analyses on "build or buy" decisions. The ROI1s vary extensively based upon the specific solution: For example, the more targeted and specific the ?disparate propriety element?, the more straight-forward is the ROI analysis. This is why the many start-ups of the late 90?s, early 2000?s, provided online "ROI calculators", because relatively simple formulas could be used to develop costlbenefit analysis, in areas such as supply chain (procurement costs), distribution (warehousing/shipping costs), demand planning (generating reliable forecasts).

The key is using both qualitative and quantitative data to generate cost savings results (improved quality, on-time deliveries, expedited processing), capturing that data effectively, and having a known baseline to start with, as indicated in the quote from Paul Fox of Gillette regarding the use of RFIDs. Fox estimates that M I D will save Gillette 20% in operational costs at each distribution center.

Many implementations, for example, make assumptions that barcoding andlor M I D will provide cost savings without having analyzed the technology and development costs and resource timeline, and without establishing/measuring the cost baseline as a starting point.

JITCAR: Does this framework allow for a project-management oriented determination of resource allocation (resource costing) as a supporting factor to the costbenefit effort with proprietary elements (as outlined above)?

Stetson: Basically, yes, if using PM tools like MS Project, or even more sophisticated tools. The development level of effort is quantified, given the timeline, resources, rates, (for both consulting and internal resources) and p l a ~ e d outcome. This assumes, of course, well-documented and detailed business requirements, functional and technical specifications that are signed off and approved. This may be difficult to do for an initial ROI analysis, but the diligence is needed to ensure reliable numbers.

JITCAR: Is ABAP (Advanced Business Applications Processing) introduced as a concurrent, horizontal phase in synch with organizationaVcorporate infrastructure configuration or at a later phase in the project cycle?

Stetson: ABAP is a proprietary programming language, and, as such, may be used extensively for development-intensive projects. As I mentioned in my 42 answer, with detailed requirements for both configuration and development, the configuration and development can be done concurrently to some extent. ABAP is introduced in the Development Phase of the project, after the ?blueprinting? or high-level design, and detailed specs are completed.

Ultimately the configuration is the final "development" task, by personalizing the business processes to map to the business/organizational specifics, after the ABAP development is Unit Tested and Integration Tested.

JITCAR, Volume 9, Number 3, 2007 50

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

JITCAR. Would you consider the biggest obstacle to ERP project buy-in (outside of any technical limitation) be focused upon the business decision-makers (illuminative of their technical ignorance, perhaps?) or with the "worker bee" who understands ERP and sees the potential for a lost job due to increases in business process efficiencies and the supply/value chain becoming streamlined?

Stetson: If I understand your question correctly, you are asking if the bamer to buy-in typically comes from the business management or operationsladrninistration personnel who fear loss of jobs? I would say the former, that often the ERP project is sold top-down, and middle management has not been appropriately included in the evaluation and decision-making process. They frequently want to hang onto their area of influence and knowledge, but with effective Change Management and Communications programs, the lack of buy-in can be turned around. This pertains to the ?worker-bees? also.

In my experience, the ERP implementations have been somewhat successful melding process and tools/technology. SAP started this early on with what was called the IMG: Implementation Guide. In fact, the same concept is still used (www.sap-img.com), and has been the basis for ASAP and other methodologies that have been developed as tools for implementations. The IMG is mapped to the data modeYconfiguration tables directly, so process and tools are integrated.

This may not be the case with in-house developed applications, as the tools group (developers, DBAs) may be different from the process group (business process mappers), so the integration may be more challenging.

P.S.: SAP has been evolving their platform and architecture over the past decade, to include and focus on .net, J2EE/Java, XML, for the front-end and NewDirnension products. However, the core application modules are still written in ABAP, and there are many clients on core R/3. Even those implementing SAP today have the choice of a GUI-based or portals-based, or mixed, approach.

I think ABAP will be with us for quite some time, as it will take years for SAP to migrate totally to .net, or web-based architecture. And the infrastructure required for .net is currently much more complex, requiring potentially higher support/IT costs. For example, the web-based components for a web-based SAP implementation include ITS (Internet Transaction Server), WAS (Web Application Server), BSPsIJSPs (Business Server Pages, or the UI), iViews (the interface between BSPs and the applications), and potentially ACE (Access Control Engineer).

NetWeaver is the bundling of these various components, including others, such as iX (Interface Server). I believe there are books on NetWeaver that go into this in much more detail, but basically some components of NetWeaver are just a "re-bundling" of existing architecture, such as BWIBI, in addition to the components mentioned above.

JITCAR: With reference to quality, compatibility, and safe guards, I looked at an analysis by the Gartner Group of quite a few vendor's for ERP, SCM, CRM, etc. and saw that there are a significant number of solutions and companies. I know you are with SAP, but in your opinion, do

JITCAR, Volume 9, Number 3, 2007 5 1

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

the majority of vendor's products realistically stack up to their stated performance?

Stetson: This is a tough question, and the answer will vary based on analyst reports, diverse client feedback, industry-specific solutions, and niche applications - these are just a few of the variables to consider when evaluating a solution. The tried and true evaluation process is still essential: conduct a thorough business requirements analysis, assess budgetaryIRO1 concerns, timelines, change readiness, overall industry health (can you afford to take the risks inherent with a major implementation given current economic health?), evaluate legacylas-is solutions' strengths/weaknesses/gaps, etc. There are many satisfied clients with various applications, but this is a very cyclical business. I am finding that there are SAP clients who move to an Oracle application platform, and vice versa. Oracle has been aggressively acquiring niche solutions and claims to have plans to "fuse" them into one solution/platform. In my experience, that is extremely difficult to achieve without a complete end-to-end redesign - a lengthy process - which is tough to achieve with a moving technology platform (Unix~XPIdistributed architecture vs. .Net)

JITCAR: New businesses are moving towards Internet connectivity as a standard for doing business. How do you think that old businesses with proprietary systems will overcome platform problems for implementing such things as supply chain visibility, collaboration, and partnering? I know some companies are trylng to create viable interfaces linking their legacy systems and the Internet, but don't you think that is only a patch?

Stetson: Yes. The "legacy systems" need to have been developed based on an architecture that addresses the specific front-end or user interface, with compatible end-to-end data models and design. Typical legacy applications are not designed with flexible techological considerations that can be easily "plugged into" a portaVweb solution. The result is usually a kludge, with major user-interface issues. This is why the ERP vendors are extending or expanding their technology platform solutions to bridge the gap between their application design and the UYportal desigdfunctionality.

JITCAR: As expensive as it is to install and implement an enterprise system, how long do the consultation, installation, and implementation companies warranty their work? What type of insurance can businesses buy to cover large system failures? How much does it cost?

Stetson: I do not know of any warranty provisions, nor insurance offerings, to cover systems implementations. By definition, an "implementation" is intended to "put into operation" a tool or application. The deliverables are development objects and configuration that is owned by the client, typically. As such, the client owns the solution and is responsible for performance and support moving forward. Thus the importance of knowledge transfer from consultants to client project team, and signoff by the client for the various milestones. By signing off, the client essentially agrees that the design will be delivered according to their requirements, and accepts the solution as configured. The exception might be clauses in the engagement contract1SOW requiring the consultants to continue the engagement based upon certain performance criteria, which is rare, as performance - system or functional - is ultimately farely subjective. The measure of success is the legacy applications turned off, and the business running on a new application, which will inevitably have hiccups during the first few monthslyear of use!

JITCAR, Volume 9, Number 3, 2007 52

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

JITCAR: In your opinion, how much time and effort should organizations spend integrating legacy systems with new updated iterations of ERP tools? When is it time to rethink the solution and start fiom scratch?

Stetson: It is difficult to say exactly how much timeleffort should be spent on integrating legacy systems with new ERP tools. I would look carefully at initial evaluationslrequirements analyses, and assess where the issues are in the failed attempts, particularly in the analyzeldesign phases. Do the detailed designs address the requirements completely? Are you doing Conference Room Pilots, or Prototypes? These exercises can help in developing a baseline solution, peforrnbg an initial end-to-end test with key users, and then getting approval on the design.

An early prototype test, or CRP, for example, can work out initial issues, and might point to problems with design/incomplete requirements, as well as get user buy-in. It is very important, I believe, to do post-mortems on initial implementations/projects also, to assess what workedldidn't. Too often projects get restarted without a thorough assessment of critical success factors.

JITCAR: You also spoke about "executive sponsorship" within organizations in relation to ERP tool integration as being key. I agree that this fosters a sense of ownership of the project as well as accountability of the end result of those involved. Again, in your opinion, from this perspective is it better to have the actual ERP tools developed in house (i.e. hire your own developers, engineers, etc to develop and see the project through to the end) to work directly withlfor the executive sponsorship, or is it better to have the work outsourced to a 3rd party contractor/consultant.

Stetson: The successful ERP projects are comprised of project team members (businesslfunctional, technical, DBA, systems admin) that are a balance of representatives from the respective client organizations, and a qualified, experienced consulting team. Typically the ERP experience and expertise is missing or minimal among the client team members, so a qualified, experienced consulting team is essential. Change Management/Communications can also be outsourced to help the management tearn/executives implement effective change management programs, if that is not a strength.

JITCAR: What do you believe is the best way for one to go about transitioning from the buildinglsupport role into that of a project manager? What are some of the initial things to avail yourself to in order to ensure that when the time comes for implementation you are not one of the project managers with experience building a project, and a lack of actual experience implementing a project?

Stetson: I reemphasize that business expertise is critical. Regardless of how technical your role is, learn about the business - the industry, the business processes, the corporate goalslobjectives, and understand what challenges are faced by management. Whether it's on-time-delivery, product quality, product design, financials, etc. etc, it is important to understand the business drivers, and know how the solutions will enhance the business processes. Excellent problem solving skills are

JITCAR, Volume 9, Number 3, 2007 5 3

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

important, as are breadth of knowledge. Budgeting and people skills are also important, as you need to manage the project budgevfinances and team (although they may have their own personneVperformance managers).

JITCAR: I was wondering if ERP does not lend itself to certain types of businesses. I have read articles about the Navy's ERP pilot program being criticized by GAO for failing:

I did not know if this is more a function of the federal government failing or a difference in opinion as to the success of the program. DoD and DON have declared some successes from the pilot programs. Are there certain types of business that you have encountered where ERP did not work well? For example, a business that is too large, spans internationaVcultura1 boundaries or for some other reasons.

Stetson: Having worked on large-scale implementations in both private and public sector, my assessment is that there are no specific limitations to effective ERP implementations. The key is to carefully define scope and delimit the parameters of the implementation. For example, at DoD the ERP projects initially focused on logistics. Across the services organizations, the Future Logistics Enterprise initiative was responsible for integrating the various logistics implementations, leveraging and integrating project methodologies.

Some of the documented and publicized ERP project "failures" were a result of the very limited project scope. Many "pilot" initiatives never became "productive" implementations. "Pilot" projects can be doomed to a pilot status indefinitely, unless a plan and budget is proposed to transition pilot to productive. This is why I believe there is a perception that projects have failed. The "pilot" initiatives were never intended to go "productive"; thus the perception that there are many projects that have been unsuccessful.

JITCAR: Are there any scenarios where a large organization can lower its consulting costs from the hefty $100M to $600 M+?

Stetson: The main reason for the high rates for ERP implementations is the product complexities and inherent configuration flexibilities that ERP experts have acquired over the course of multiple implementations. It is not feasible to train a project team, and provide the project team with knowledge transfer and requisite experience, in a short period of time. This comes from years of experience with an ERP vendor's solution, and industry experience with various implementations.

Smaller companies ($100M - $500M) are successful with short implementations because they reduce the complex and varied requirements. ERP vendors are increasingly more successful with SMB implementations because of implementation methodologies and tools, and reduced and controlled scope.

JITCAR: Some of the issues that can arise when project teams are more IT lead - which can lead to scope creep. In order to minimize this, what area of management should take the lead in such an operation?

JITCAR, Volume 9, Number 3, 2007 54

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

Stetson: The business leads should be primarily responsible for driving to the key deliverables and milestones for an ERP project. As lead members of the business community, they should be knowledgeable, responsible, and in a leadership role to direct the ERP project. Without the appropriate business leadership, projects can run "off-course" and are subject to the risk of becoming too IT-drivenlcentric. The business community should be in a position to identifl the ROI factors that will ultimately determine the success of an ERP project, and therefore the business leaders should be an integral part of the project organization, decision-making processes, and milestone schedule.

JITCAR: In your opinion would it behoove an organization to provide a certain amount of "across the board" training so that all segments of the organization have an understanding of what the other parts are dealing with or is this something that is best left to the organization to deal with after the ERP training is over?

Stetson: I am a strong proponent of lots of training, including an initial "35,000 ft." overview, to understand the integration and dependencies. This should be done as soon as a decision on the solution is made, and the project team is formed. The entire team, both core members and extended team, as well as executive team, should understand the breadth and connectivity, and integrated aspects of the ERP system. This training overview is often overlooked, and causes problems with buy-in and user acceptance.

JITCAR: This was an excellent interview. Thank you so much for your insightful responses. Real experience with the technologies, business practices and lessons learned are invaluable to the readers of this article.

Interviewer's Comments:

Key points/takeaways from this Expert Opinion are as follows:

- Companies implement ERP systems to reduce the high cost of IT and satisfy a need to provide better and robust business solutions.

- Businesses must plan for the future as they build their ERP systems. They can't just cut the systems integrators (SI) loose the day the system goes live, as the SI's must be accountable for their work

- People and training are an important part of the ERP system. Internal training helps people buy- in to the new system. Training should not be done on a development system as first impressions are key to making people feel comfortable. You want to help people do their jobs with the new system, not provide them with a new obstacles. Change management plays a big role in this ,

process.

- Businesses must drive the change, not the SI. You can't just let the SI take over without any controls. The business requirements must be driven by the customer, not the SI.

JITCAR, VoIume 9, Number 3, 2007 55

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014

The Expert Opinion Report

In conducting this interview, I found a recent article focusing on the implementation of RFIDs as an interesting example of the challenges of calculating a ROI when opting to use new technologies. The RFID technology has been evolving quite quickly to the point where companies who were early adopters of the technology have seen a big change in the technologies capabilities and a substantial reduction in RFID costs over the lifetime of their implementations. While the cost reductions are a big plus, implementations based on limited capabilities may no longer be the best solution.

In this example, the RFID technology has been a moving target, which highlights in my mind at least that any WID ROI calculation and implementation plan needs to take that into consideration. This reinforces the concept that the employment of any enterprise application needs to be an on going process as opposed to a one and done philosophy we see all to often in the real world. It is not hard to imagine that in the not too distant future that RFID technology will be systemic throughout the value chain as opposed to being relegated predominantly to the back- end systems as it is today. Moreover, businesses that are able to meld their value chain processes to the advances in technology will benefit the most when it comes to their bottom line.

Mahesh S. Raisinghani, is an associate professor in the Executive MBA program at the TWU School of Management. He is a Certified E-Commerce Consultant (CEC) and a Project Management Professional (PMP). Dr. Raisinghani was the recipient of TWU School of Management's 2005 Best Professor Award for the Most Innovative Teaching Methods; 2002 research award; 2001 KingIHaggar Award for excellence in teaching, research and service; and a 1999 UD-GSM Presidential Award. His previous publications have appeared in IEEE Transactions on Engineering Management, Information and Management, Journal of IT Cases and Applications, Journal of Global LT. Management, Journal of E-Commerce Research, Information Strategy: An Executive's Journal, International Journal of E-Business Research, Journal of IT Review, Information Resources and Management Journal, Journal of I.T. Theory and Applications, Enterprise Systems Journal, Journal of Computer Information Systems and Information Systems Management among others.

JITCAR, Volume 9, Number 3, 2007

Dow

nloa

ded

by [

Um

eå U

nive

rsity

Lib

rary

] at

04:

17 0

4 O

ctob

er 2

014