Professional Documents
Culture Documents
Enterprise Resource Planning Systems Review Questions
Enterprise Resource Planning Systems Review Questions
Review Questions
1. Define ERP.
Response: ERP systems are multiple module software packages that evolved primarily
from traditional manufacturing resource planning (MRP) systems.
The objective of ERP is to integrate key processes of the organization such as order entry,
manufacturing, procurement and accounts payable, payroll, and human resources. By doing so, a
single computer system can serve the unique needs of each functional area.
20. How is the access control list approach different from RBAC?
Response: The access control list approach assigns access directly to the individual.
RBAC assigns permissions to a role and then the individual is assigned to the role. It is a way of
dealing efficiently with the many-to-many relationship between individuals and permissions.
21. Search the Web: How is the Oracle database different from relational databases?
Response: Responses may vary.
Discussion Questions
2. Distinguish between the two-tier and three-tier client-server models. Describe when each
would be used.
Response: In a two-tier architecture, the server handles both application and database
duties. Some ERP vendors use this approach for local area network (LAN) applications. Client
computers are responsible for presenting data to the user and passing user input back to the
server. In the three-tier model the database and application functions are separated. This
architecture is typical of large production ERP systems, which use wide area networks (WANs)
for connectivity. Satisfying a client request requires two or more network connections. Initially,
the client establishes communications with the application server. The application server then
initiates a second connection to the database server.
3. Why do ERP systems need bolt-on software? Give an example of bolt-on software.
Response: Many organizations have found that ERP software alone cannot drive all the
processes of the company. These firms use a variety of bolt-on software provided by third party
vendors. At present, most electronic commerce supported ERP systems use bolt-on packages that
upload product information files from the ERP database and present them on the web page for
customers. The bolt-on system collects the Internet orders and creates a transaction batch file,
which is periodically downloaded to the ERP system for processing. This situation is changing
rapidly. With increased demand from customers for real-time commitments from their
manufacturers regarding price, manufacturing schedule, and delivery date, leading ERP suppliers
are being forced to make their systems web-enabled.
4. Your organization is considering acquiring bolt-on software for your ERP system. What
approaches are open to you?
Response: The decision to use bolt-on software requires careful consideration. Most of
the leading ERP vendors have entered into partnership arrangements with third party vendors to
provide specialized functionality. The least risky approach is to choose the bolt-on that is
endorsed by the ERP vendor. Some organizations, however, take a more independent approach.
This sometime requires changing the core function code to interface with the bolt-on software.
5. Explain why the data warehouse needs to be separate from the operational database.
Response: One reason for a separate data warehouse is that the structural and operational
requirements of transaction processing and data mining systems are fundamentally different,
making it impractical to keep both operational (current) and archive data in the same database.
Transaction processing systems need a data structure that supports performance, whereas data
mining systems need data organized in a manner that permits broad examination and the detection
of underlying trends.
6. Data in a data warehouse are in a stable state. Explain how this can hamper data mining
analysis. What can an organization do to alleviate this problem?
Response: Typically transaction data are loaded into the warehouse only when the
activity on them has been completed e.g., they are stable. Potentially important relationships
between entities may, however, be absent from data that are captured in its stable state. For
example, information about cancelled sales orders probably will not be reflected among the sales
orders that have been shipped and paid for, before they are placed in the warehouse. One way to
reflect these dynamics is to extract the operations data in slices of time. These slices provide
snapshots of business activity.
7. This chapter stressed the importance of data normalization when constructing a relational
database. Why, then, is it important to denormalize data in a data warehouse?
Response: Wherever possible, normalized tables pertaining to selected events should be
consolidated into denormalized tables. Because of the vast size of a data warehouse, inefficiency
caused by joining normalized data can be very detrimental to the performance of the system. A
three-way join between tables in a large data warehouse may take an unacceptably long time to
complete and may be unnecessary. Since historical data are static in nature, nothing is gained by
constructing normalized tables with dynamic links.
9. How are the summary views in a data warehouse different from views in an operational
database?
Response: To improve operational efficiency, certain data are transformed into summary
views before they are loaded into the warehouse. For example, a decision maker may need to see
product sales figures summarized for a week, a month, a quarter, or annually. It may not be
practical to summarize information from detail data every time the user needs it. A data
warehouse can contain the most frequently requested summary views of data and reduce the
amount of processing time during analysis. These are typically created around business entities
such as Customers, Products, and Suppliers. Unlike views in an operational database, which are
virtual in nature with underlying base tables, data warehouse views are denormalized physical
tables.
10. Would drill-down be an effective audit tool for identifying an unusual business relationship
between a purchasing agent and suppliers in a large organization with several hundred suppliers?
Explain.
Respones: Yes. The auditor may use drill-down techniques to identify unusually high
levels of business activity for a particular supplier. Excessive purchases from a single supplier
could represent an abnormal business dependency that may prove harmful to the firm if the
supplier raises prices or cannot deliver on schedule. It may also signify a fraudulent relationship
involving kickbacks to purchasing agents or other management.
11. Disruptions to operations are a common side effect of implanting an ERP. Explain the
primary reason for this.
Response: The reengineering of business processes that often accompanies ERP
implementation is the most commonly attributed cause of performance problems. Operationally
speaking, when business begins under the ERP system, everything looks and works differently
from the way it did with the legacy system. An adjustment period is needed for everyone to reach
a comfortable point on the learning curve. Depending on the culture of the organization and
attitudes towards change within the firm, adjustment may take longer in some firms than in
others.
12. ERP systems use the best-practices approach in designing their applications, yet goodness of
fit is considered to be an important issue when selecting an ERP. Shouldn’t the client just be able
to use whatever applications the ERP system provides?
Response: When a business’ processes are truly unique, the ERP system must be
modified to accommodate industry specific (bolt-on) software or to work with custom-built
legacy systems. Some organizations, such as telecommunications service providers, have unique
billing operations that cannot be satisfied by off-the-shelf ERP systems. Before embarking on the
ERP journey, organization management needs to assess whether they can and should reengineer
their business practices around a standardized model.
13. Explain the issues of size, speed, workload, and transaction as they relate to scalability.
Response: Size. With no other changes to the system, if database size increases by a
factor of x, then query response time will increase by no more than a factor of x in a scalable
system. For example, if business growth causes the database to increase from 100GB to 500GB,
then transactions and queries that previously took one second will now take no more than five
seconds.
Speed. An increase in hardware capacity by a factor of x will decrease query response time by no
less than a factor of x in a scalable system. For example, by increasing the number of input
terminals (nodes) from one to twenty, transaction processing time will decrease proportionately.
Transactions that previously took twenty seconds will, because of more terminals, now take no
more than one second in a system with linear scaling.
Workload. If workload in a scalable system is increased by a factor of x, then response time or
throughput can be maintained by increasing hardware capacity by a factor of no more than x. For
example, if transaction volume increased from 400 per hour to 4000 per hour, the previous
response time can be achieved time by increasing the number of processors by a factor of ten in a
system that is linearly scalable.
Transaction cost. In a scalable system, increases in workload do not increase transaction cost.
Therefore, an organization should not need to increase system capacity faster than demand. For
example, if the cost of processing a transaction in a system with one processor is ten cents, then it
should still cost no more that ten cents when the number of processors is increased to handle
larger volumes of transactions.
14. Explain how SAP uses roles as a way to improve internal control.
Response: Roles support the objectives of segregation of duties. Each role is associated
with a specific set of activities, which are assigned to an authorized user of the ERP System. SAP
currently provides over 150 predefined user roles, which limit a user’s access to only certain
functions and associated data. The system administrator assigns roles to users of the system when
it is configured. These can be customized as needed. When the user logs on to the system, a role-
based menu appears, which limits the user to the specified tasks. Auditors should ensure that roles
are assigned in accordance with job responsibilities on a “need-to-know” basis.
15. How would you deal with the problem of file-server backup in a highly centralized
organization?
Response: Centralized organizations with highly integrated business units may need a
single global ERP system that is accessed via the Internet or private lines from around the world,
to consolidate data from subsidiary systems. A server failure under this model could leave the
entire organization unable to process transactions. To control against this, two linked servers can
be connected in redundant backup mode. All production processing is done on one server. If it
fails, processing is automatically transferred to the other. Organizations that want more security
and resilience may arrange servers in a cluster of three or more that dynamically share the
workload. Processing can be redistributed if one or more of the servers in the cluster fail.
16. How would you deal with the problem of file-server backup in a decentralized organization
with autonomous divisions that do not share common operational data?
Response: Companies whose organizational units are autonomous and do not share
common customers, suppliers, or product lines often choose to install regional servers. This
approach permits independent processing and spreads the risk associated with server failure. For
example, BP Amoco implemented SAP’s R/3 into 17 separate business groups.
18. When would slicing and dicing be an appropriate OLAP tool? Give an example.
Response: Slicing and dicing enables the user to examine data from different viewpoints.
One slice of data might show sales within each region. Another slice presents sales by product
across regions. Slicing and dicing is often performed along a time axis to depict trends and
patterns.
19. Explain the risks associated with the creation of unnecessary roles and why it can happen.
Response: Managers in ERP environments have significant discretion in creating new
roles for individuals. This may be done for employees who need access to resources for special
and/or one-time projects. Such access granting authority needs to be tempered with judgment to
prevent the number of roles from multiplying to the point of becoming dysfunctional and thus
creating a control risk. Indeed, an oft cited problem in ERP environments is that roles tend to
proliferate to a point where their numbers actually exceed the number of employees in the
organization. Policies need to be in place to prevent the creation of unnecessary new roles and to
ensure that temporary role assignments are deleted when the reason for them terminates.
20. What is the fundamental concept behind the rule of least access? Explain why this is a
potential problem in an ERP environment.
Response: The fundamental concept behind the rule of least access is that access
privileges (permissions) should be granted on a need to know basis only. Nevertheless, ERP users
tend to accumulate unneeded permissions over time. This is often due to two problems:
Managers fail to exercise adequate care in assigning permissions as part of their role granting
authority. Since, managers are not always experts in internal controls they may not recognize
when excessive permissions are awarded to an individual.
Managers tend to be better at issuing privileges than removing them. As a result, an individual
may retain unneeded access privileges from a previous job assignment that creates a segregation
of duties violation when combined with a newly assigned role
Multiple Choice
1. B
2. E
3. D
4. E
5. E
6. C
7. C
8. B
9. C
10. E
Problems
Response:
Merit: The primary reason for a data warehousing is to optimize the business. Many
organizations’ management personnel feel that more strategic benefit can be gained by sharing
data externally. By providing customers and suppliers with the information they need when they
need it, the company can improve its relationships and provide better service. The potential gain
to the giving organization is seen in a more responsive and efficient supply chain. Using Internet
technologies and OLAP applications, an organization can share its data warehouse with its
trading partners and, in effect, treat them like divisions of the firm.
Control: Access control is a vital feature of a data warehouse that is shared with customers and
suppliers. The following control issues need to be considered:
The organization should establish procedures to oversee the authorization of individuals
at customer and supplier sites which will be granted access to their data warehouses.
Access privileges should be specified for each outside user and controlled by the use of
passwords.
User views need to be created that will limit outsider access to only approved data.
Internet sessions should be managed by means of a firewall and use encryption and
digital signatures to maintain confidentiality.
Firewalls, which are a combination of hardware and software that protect resources of a
private network, help to secure data from unauthorized internal and external users.
Auditing tools for intrusion detection are available to assist in mitigating security risks.
Periodic audits should include a risk assessment and review of access levels granted to
both internal and external users, based on their job descriptions.
2. Project Implementation
Your organization is planning to implement an ERP system. Some managers in the organization
favor the big bang approach. Others are advocating a phased-in approach. The CEO has asked
you, as project leader, to write a memo summarizing the advantages and disadvantages of each
approach and to make a recommendation. This is a traditional organization with a strong internal
hierarchy. The company was acquired in a merger 2 years ago, and the ERP project is an effort on
the part of the parent company to standardize business processes and reporting across the
organization. Prior to this, the organization had been using a general ledger package that it
acquired in 1979. Most of the transaction processing is a combination of manual and batch
processing. Most employees think that the legacy system works well. At this point, the
implementation project is behind schedule.
Response:
While the big bang method has certain advantages, it has been associated with numerous system
failures. Since the new ERP system means new ways of conducting business, getting the entire
organization on-board and in sync can be a problem. On day one of the implementation, no one
within the organization will have had any experience with the new system. In a sense, everyone in
the company is a trainee learning a new job. The new ERP will initially meet with opposition,
because using it involves compromise. The legacy systems, with which everyone in the
organization was familiar, had been honed over the years to meet exact needs. In most cases, ERP
systems have neither the range of functionality, nor the familiarity of the legacy systems which
they replace. Also, because a single system is now serving the entire organization, individuals at
data input points often find themselves entering considerably more data than they did previously
with the more narrowly focused legacy system. As a result, the speed of the new system often
suffers, causing disruptions to daily operations. These problems are typically experienced
whenever any new system is implemented. The magnitude of the problem is the issue under the
big-bang approach where everyone in the company is affected. Once the initial adjustment period
has passed and the new culture emerges, however, the ERP system becomes an effective
operational and strategic tool that provides competitive advantage to the firm.
Because of the disruptions associated with the big bang, the phased-in approach has emerged as a
popular alternative. It is particularly suited to diversified organizations with units that do not
share common processes and data. In these types of companies, independent ERP systems can be
installed in each business unit over time, to accommodate the adjustment periods needed for
assimilation. Common processes and data (such as the general ledger function) can be integrated
across the organization without disrupting operations throughout the firm.
To be successful, all functional areas of the organization need to be involved in determining the
culture of the firm and in defining the new system’s requirements. The firm’s willingness and
ability to undertake a change of the magnitude of an ERP implementation is an important
consideration. If the corporate culture is such that change is not tolerated or desired, then an ERP
implementation will not be successful.
The technological culture must also be assessed. Organizations that lack technical support staff
for the new system, or have a user base that is unfamiliar with computer technology, face a
steeper learning curve and a potentially greater barrier to acceptance of the system by its
employees.
All things considered, a phased-in approach is more likely to be successful with this organization
culture.
Response:
a. On-line transaction (OLTP) processing is appropriate because the amount of data accessed
is limited, few business elements are analyzed, the data is not aggregated, and the time
frame is finite.
b. On-line analytical processing (OLAP) is appropriate because analysis of data over
several years is required.
c. OLAP because that data being analyzed spans several regions.
d. OLAP. While this system will analyze simple transactions, the volume of activity and
the analytical procedures may require greater resources than OLTP can provide.
e.. OLAP. OLAP supports consolidation of data, drill-down analysis, and slicing and
dicing.
f. OLAP. While OLTP has been sufficient to provide the information requirements to
date, the company is not meeting its goals, and an understanding of the business processes,
related phenomena, and comparisons among processes is indicated. Analyses in these areas may
help the company determine better business practices. OLAP will provide the company with the
analytic tools that may help management find better ways to operate.
4. Selecting a Consultant
You are the chief information officer for a midsized organization that has decided to implement
an ERP system. The CEO has met with a consulting ERP firm based on a recommendation from a
personal friend at his club. At the interview, the president of the consulting firm introduced the
chief consultant, who was charming, personable, and seemed very knowledgeable. The CEO’s
first instinct was to sign a contract with the consultant, but he decided to hold off until he had
received your input.
Required:
Write a memo to the CEO presenting the issues and the risks associated with consultants. Also,
outline a set of procedures that could be used as a guide in selecting a consultant.
Response:
Consulting firms, particularly the big four with large ERP practices, are desperately short of
human resources at times. We saw this in the mid-to-late 1990s when thousands of clients were
rushing to implement ERP systems before the new millennium, and thus avoid Y2K problems. As
demand for ERP implementations grew beyond the supply of qualified consultants, more and
more stories of botched projects materialized.
A common complaint is that consulting firms promise experienced professionals but deliver
incompetent trainees. They have been accused of employing a bait-and-switch maneuver to get
contracts. At the initial engagement interview, the consulting firm introduces their top consultants
who are sophisticated, talented, and persuasive. The client agrees to the deal, incorrectly
assuming that these individuals, or others with similar qualifications, will actually implement the
system. The problem has been equated to the airline industry’s common practice of overbooking
flights.
Consulting firms, not wanting to turn away business, are perhaps guilty of overbooking their
consulting staff. However, the consequences are far graver than the inconvenience of missing a
flight. Currently a number of lawsuits have been filed against the consultants of failed ERP
projects. We can avoid these pitfalls by selecting the right consultant. Therefore, before turning
the problem over to just any outside consultant, we need to do the following:
Interview the staff proposed for the project and draft a detailed contract specifying which
members of the consulting team will be assigned to which tasks.
Obtain an agreement in writing as to how staff changes will be handled.
Conduct reference checks of the proposed staff members.
Align the consultants’ interests with those of the organization by negotiating a pay-for-
performance scheme, based on achieving certain milestones in the project. For example, the
actual amount paid to the consultant may be between 85 to 115 percent of the contracted fee,
based on whether a successful project implementation comes in under, or over, schedule.
Set a firm termination date for the consultant. There is a lot of evidence that consulting
arrangements can become interminable, resulting in dependency and an endless stream of fees.
Response:
While organization’s data warehouse is an excellent resource for performing analytical reviews, I
will need to gain an understanding of the procedures used to populate the warehouse. I am
concerned that your data cleansing procedures may be sanitizing the warehouse, which could
create a false picture of your financial position. To be useful as an OLAP tool, the data warehouse
needs to be free of contamination. Erroneous data (such as negative inventory values, missing
fields, and other clerical errors) that are a natural part of operational databases are identified and
repaired (or rejected) in the cleansing process prior to their entering the data warehouse. Since the
data warehouse exists in an artificially pristine state, it may not be a suitable substitute for the
operational database when assessing tests of process controls and performing substantive tests. I
must, therefore, perform tests of your cleansing procedures before I can place reliance on the data
warehouse as a resource for substantive testing.
Response:
Either approach would require transformation of data from the legacy systems to a
common data warehouse. A phased-in approach has an advantage of uncovering discrepancies
among data at a single site. Once the discrepancies are found, the resulting bugs can be corrected,
so relatively error-free systems can be placed in other sites.
Presuming the goals of a DMV are to correctly tax and license drivers and vehicles, and
to do so expediently, the fact that customers were waiting too long and that many chose not to
comply with the law requiring they become properly licensed, organizational goals were not met
with the big bang approach. Again, a phased-in approach might have uncovered these problems
and found corrections on a local rather than state-wide basis.
The employees seemed to lack adequate training and seemed not to support the new
system. Phasing-in a new system does not require as many technicians, as the instruction process
can take place over time and across geography. With an increased number of required
technicians, there is a decreased the chance that all technicians will be familiar with the system
and the requirements. Therefore, a phased-in approach might have supplied the DMV with better
instruction. The big bang approach also seemed to catch the employees off guard. It is possible
that if a phased-in approach had been used, the process might have gone more smoothly, and
word-of-mouth about the system (and its probable improvement over the legacy systems) might
have lessened the resistance to change on the part of employees anticipating their own phasing-in.
If customers were satisfied with the service they received, and if employees were
adequately trained and accepting of the new system, (probable consequences of a phase-in), the
DMV could have avoided loss of revenue resulting from customer reluctance to register vehicles
and obtain licenses.
7. ERP Failure
When an ERP implementation fails, who is to blame? Is it the software manufacturer, the client
firm, or the implementation strategy?
Response:
Who is to blame for ERP failure?
By Barry Calogero, “Who is to blame for ERP failure?”, Serverworld Magazine,
http://www.serverworldmagazine.com/sunserver/2000/06/erp_fail.shtml
Enterprise Resource Planning (ERP) tools, or enterprise-wide client/server applications
for managing accounting, manufacturing, distribution and human resources have become the de
facto backbone of business intelligence. As more and more organizations across the globe have
chosen to build their corporate knowledge-base around this class of complex infrastructure tools,
the implementation challenges have become evident.
These challenges have been well publicized in the leading business periodicals,
underscoring organizational frustrations and even total meltdowns. Whirlpool and Gore-Tex
recently blasted SAP and PeopleSoft in separate front page articles in “The Wall Street Journal”
articles, highlighting serious business consequences and blaming these leading ERP vendors and
implementing consultants for botched deployments. What’s more, the nation’s leading chocolate
manufacturer, Hershey Food Corp., recently noted that it has lost its taste for SAP, holding the
vendor accountable for order processing problems that hampered its ability to ship candy and
other products to retailers around the peak Halloween season.
In reality, however, the software giants are not to blame for these high-profile failures.
The customers are not to blame either. The real culprit is the process.
Revising implementation management strategies can put ERP solutions back on a successful path.
At the root of many ERP problems lies one overlooked but critical step: new business processes
must be established, thought through, and implemented before software tools are selected,
purchased, and rolled out.
As showcased in the recent media articles, business evolution to ERP is about more than software
tools. Herein lies the greatest challenge for end-user organizations and consultants working to
implement solutions. To an even greater degree, the success of an ERP implementation is gauged
by its ability to align IT and business management objectives, supply demanding program
management skills and provide a refined process for success.
To add to the complexity, the software world today is undergoing a significant
transformation, with many vendors adapting the popular Web-enabled Application Service
Provider (ASP) model. ASPs lease software to organizations via the Web. Although some will try
to apply this model to ERP implementations, it may well serve to add additional complexity and
remove much of the critical business process planning that can make or break the
implementation. In addition, it will likely encourage “square-pegs-in-round-holes” ERP
implementations, in which organizations spend significant dollars to buy a technology—and are
then forced to squeeze their business processes to fit the mold of the purchased technology. There
may be opportunities to marry ERP with the Web through front-end technologies, giving users
access to the system through browser-based alternatives to the traditional client-server paradigm.
Whatever model they choose to roll out, an organization’s success will depend on redesigning the
process and customizing the technology to fit that process—rather than the other way around.
Required: Research this issue and write a brief paper outlining the key issues.
Response:
By Jon Surmacz
June 5, 2002
The overall enterprise resource management (ERP) market grew 4 percent in 2001, even
as traditional ERP investments (financials, human resources, production management) dropped 3
percent, according to a recent report by Boston-based AMR Research. AMR predicts that ERP
vendors will soon derive most of their revenues from adding customer relationship management
(CRM), supply chain management (SCM) and product lifecycle management (PLM) capabilities.
These extensions produced $4 billion of the $20 billion of total vendor revenue in 2001,
according to the report. By 2006, they will make up half of vendor revenues.
“Where we see the growth opportunity is in the strategic extensions, big things like CRM and
supply chain capabilities,” says Colleen Nevis, vice president of research, enterprise applications,
at AMR. “The growth is not going to be based on core ERP.” Nevis says companies that made
ERP investments during the boom of the mid-90s are now interested in adding small modules and
tying their front-office systems to their back-office systems. Although AMR estimates that the
total ERP market will grow from $19.8 billion to $31.4 billion in 2006 at a compound annual
growth rate of 10 percent, most of this will not be the result of core ERP software sales. Most
companies have not budgeted for such upgrades, nor will they for a long time. Nevis says upgrade
cycles that formerly ran 5 to 7 years are now growing to 10 to 15 years. “People who bought ERP
systems in the ERP goldrush of the mid-90s aren’t going to be replacing those until at least
2006,” Niven says; “more likely 2010.” Companies that didn’t invest during the boom—namely
government organizations and service industries—may be ready to do so now. “Industries and
trends where people didn’t invest are where the opportunities are now,” Niven says. “Service
industries made ERP investments in the late 80s and early 90s. They didn’t participate in the
boom of the mid-90s.” AMR predicts that core ERP will make gains in the mid-markets,
however. Most activity to date has come from the high mid-market segment ($250 million to $1
billion in revenue), says Niven, but the lower segment ($10 million to $50 million in revenue) is
now showing significant growth. Overall, the mid-market ERP segment will show 10 percent to
15 percent growth over the next four years. “In 1999, we all thought that mid-market ERP was an
untapped market,” Niven says. “But at the same time there were hundreds of vendors in the
market. Since then, that market has consolidated quite a bit. It’s become much more mature as far
as vendors.”
9. ERP Consultants
Do an Internet search of complaints about ERP consultants. Write a report about the most
common complaints and cite examples.
Response:
Beware ERP Consultants
Since 1998, K2 Enterprises has documented dozens, if not hundreds, of complaints from the
attendees of our accounting software and enterprise software courses concerning the practices of
enterprise consultants. We do not need to name names, we all know who they are. Over time we
were able to determine that the complaints that we receive generally fall into one of the five
categories. List below are the complaints we hear most often:
2. The information is simply not available to allow you to properly evaluate the enterprise class
products.
Based on the previous complaint, you would probably save yourself a great deal of time
and money and arrive at a better decision by performing the needs analysis yourself.
Unfortunately the “system” does not always work that way. Often the vendors won’t provide you
with the information you need to properly evaluate the product and the high-priced consultants
won’t provide this information either without the “big bucks”. Amazingly, some of the enterprise
vendors have a built in incentive not to share this information with you for example—in J. D.
Edwards case, we understand that the vendor pockets 15% of the consulting fees collected by all
of the “approved” J. D. Edwards consultants.
You can tell by evaluating the J. D. Edwards web site in particular that the details about
the product are kept secret. On this web site you will find no screen shots, no detailed feature
lists, no Citrix access to the product, no pricing information, and very little helpful data. The J. D.
Edwards web site was obviously written by marketing people who are more interested in “selling
the dream” as opposed to technical writings that “sell the reality”. Your best option may be to
work with the enterprise vendors directly to obtain the data and product demonstrations you need.
As proof, consider the screen shot below captured on May 29, 2001: This is the entire description
of the J. D. Edwards Financial Reporting capabilities according to the J. D. Edwards web site:
Surely this powerful product offers more features than the scant description above reveals. In this
day and age, what explanation would there be for not providing in-depth information about their
products? You may think that they prefer to keep details of their product a secret so that they
don’t fall into hands of their competitors. This is a rather silly notion as their competitors already
have access to J. D. Edwards system, as well as one another’s systems.
We’ve seen this problem first hand. In early 2000, K2 Enterprise instructors invited J. D.
Edwards personnel to accompany us on a consulting engagement in which a $200 million
customer was considering the purchase of J. D. Edwards One World. The 8-hour meeting was
held in Denver just a few miles from J.D. Edwards headquarters. Our main goal was to introduce
our customer to the folks at J. D. Edwards and have them sit in and help answer questions about
their product, or at least to ensure that the answers we gave were accurate. The engagement came
and passed—five K2 instructors delivered an 8-hour presentation to 80 financial professionals
within this organization. Amazingly the folks at J. D. Edwards never even bothered to respond to
our repeated request. It appears that you can more advice from the sales clerk at the fish store
about choosing guppies than you can from a J. D. Edwards representative about choosing J. D.
Edwards software. For a potential purchase that would most certainly exceed $1 million, you
would expect to receive some assistance—wouldn’t you? It might be understandable that there
was no one in the organization with the available time and budget to attend this meeting—but this
meeting took place only a few blocks for the J. D. Edwards world-wide headquarters—surly
someone could have come down the road and shaken hands for a few minutes, or something?
To be fair, some of the other web sites are very well done. For example, the SAP web site
contains an enormous amount of information about its product, and they even provide web access
to their live product through their web site. There is no doubt that SAP is not afraid to provide
customers with the information they need to make informed decisions.
3. Enterprise consulting firms champion customization as a way to increase their fees. Many
attendees have complained to us that consulting firms are often too eager to customize the
enterprise product to the moon in back—all in the name of tailoring the solution to your exact
needs. However our feedback suggests that it is over zealous customization recommendations,
which cause most enterprise installations to break the budget and drag on forever. For example, in
1998 Eastman Kodak reported that after 3 years and $500 million, they were scrapping their
implementation of SAP software. A contact at SAP blamed the consultants for trying to
customize all of the user screens—and sure enough, SAP walked in a was able to get the product
up and running within 6 months and now Eastman Kodak is a key reference site for SAP.
Our advice to you is to implement the product and use it for 6 months before you begin
any customization work (other than obvious customization needs). After 6 months you will be in
a much better position to identify what needs fixing and what doesn’t—thereby reducing your
fees and shorting your implementation time frame dramatically.
To be fair, we freely acknowledge that customization capabilities are one of the most
important factors to consider when selecting an accounting software package. It would be
hypocritical of us to recommend customization capabilities on one hand, and on the other hand
criticize enterprise class consultants for embracing customization tools and recommending
customizations. You can see the problem we have here. However, the caliber of complaints that
we’ve heard seem to indicate that these enterprise class consultants are “customization happy”
just for the sake of churning WIP, not for the sake of solving a company’s needs. In the example
above, SAP folks told us that their product worked fine right out of the box once they replaced
the customized mangled mess that the enterprise consultants had installed. They pointed out that
Kodak was happy with their out-of-the box solution months after the installation was completed,
and that in their opinion, the vast majority of the previous customizations undertook by the
enterprise consultants were unnecessary.
Important Caveats:
OK, we’ve thoroughly trashed the enterprise consultants. Our apologies to anybody who
is offended. We are aware that we have concentrated only on the ugliness, and it is probably
warranted that we take time to tell you about some of thousands of happy companies out there
who swear by their enterprise class consultants rather than swear at them. Hey, you will find these
types of testimonials sprinkled all over their web sites and we are sure that these testimonials are
accurate. For this reason we won’t repeat any of that flowery verbiage here. We’ve presented a
one-sided story here and admit that. We all understand that this section of materials was designed
to warn you of possible problems that customers will want to avoid.
Now let’s take this conversation another way. In many cases the actual consultants we
have dealt with have been both knowledgeable and a pleasure to work with. It appears that it is
the bureaucratic organization, as opposed to the individual consultants, cause the most problems.
Many enterprise consultants agree with the observations we have made above—but discount
these problems as a necessary part of a large consulting organization. In particular here are two
very strong arguments for retaining the services of an enterprise class consulting firm that you
should keep in mind:
Caveat # 1. Please be aware that the evaluation process does involve a great deal of
sophisticated understanding of your current needs. You may or may not possess that talent or
have that talent on board in your organization. If you do not possess this talent, then hiring an
enterprise class consultant may be absolutely necessary. Of course then you are back to the
problem of the possibility that they will only recommend to you the product that they know
best—regardless of what the evaluation reveals.
Caveat # 2. Perhaps the most important issue you need to consider here is that
implementation of an enterprise class product is often far more involved than simple installation
and training. In many cases, the act of migrating to a new enterprise system is an opportunity to
re-define your business processes, your lines of communication, your internal procedures, and
your organizational structure. Accordingly, an enterprise class consulting firm has better skills to
help you identify and implement such measures. If the results eventually allow your organization
to operate in a far more streamlined environment, then the consulting firm will probably be worth
the big bucks you pay. However if you are looking for a simple selection and implementation and
training engagement—you will probably pay way more than you need to.
Caveat # 3. Large organizations have a tremendous task on their hands coordinating and
orchestrating a sophisticated implementation across multiple countries and oceans. The man-
power needs alone make it almost a necessity to employee the services of a large enterprise
consulting firm. Hey, K2 Enterprise instructors could maybe install SAP in a Fortune 500
organizations, it would only take us about thirty years or so.
You are visitor number to this page since January 10, 2000
This page was last updated on Saturday, July 13, 2002
This web site is published and maintained by K2 Enterprises—a company that delivers
technology based seminars. Reminder—You should confirm the information contained in this
web site with another source before relying on that data. Products change, prices change,
everyday.
Read our Disclosure Statement
Copyright © 1996—2002 Accounting Software World, K2 Enterprises.
All rights reserved. No part of this information can be re-printed without express written consent
of the editor.
Response:
Responses may vary.