Introduction
Organizations
considering the implementation of a resource management system are often faced
with the decision of purchasing a packaged solution or building their own custom
application.
Both
choices have their pros and cons. A decision that favors either route depends
on a number of factors whose influence on the decision process varies between
organizations. As a result, there is no golden rule that can help organizations
choose one route over the other. Whatever the route, organizations generally
inherit all that is good and bad about that option and are subsequently excluded
from the good and bad of the alternative. Furthermore, once embarking on a route
it is difficult and expensive to change course.
This
article discusses the decision factors weighed by customers in the build versus
buy debate and explores a new option, one that lies somewhere between build
or buy and offers the best of both choices.
This
article has been sponsored
by SYSPRO
Background
Prior
to the advent of packaged software, organizations wishing to implement software
solutions had no choice but to build a custom application that met their needs.
This situation changed in the nineteen eighties as software developers realized
the commercial opportunity in developing applications that addressed the common
processes and needs of many organizations. Since then, the software industry
has seen the continuous return of the build versus buy debate and vendors in
both camps periodically switch sides, depending on which option enjoys the strongest
support and has the greatest potential to drive increased revenues at the time.
During
the nineteen nineties, accelerated technology advancement in market niches increased
the number of business applications and core building blocks available in the
market. While this resulted in greater choice for customers, it also lead to
greater confusion and complexity.
Still,
these options did little to squelch the build versus buy debate. Now, instead
of buying the technology stack and applications of a single vendor, customers
were deciding on a level of vendor-centricity and augmenting this with other
best-of-breed packaged solutions. If anything, this only increased the number
of arguments instead of improving the customers' ability to take advantage of
the benefits of both camps.
For
sake of brevity, this article refrains from delving too deeply into the differences
between these options. Fully explaining both sides of every option and comparing
them against one another will take too long and in all likelihood will just
fuel an ongoing argument. Instead, we will focus only on the basic options which
all other options fall under to a lesser or greater degree: build or buy—packaged
solutions versus custom applications. This article will illustrate the benefits
and abilities of new emerging technologies that offer a more "middle of the
road" approach that should benefit all.
Buy (Packaged Solution)
The
advantage of the buy strategy is that, in theory, a package will enable the
organization to go live with broad functionality in a short period. This is
primarily because the vendor has already developed the functionality and because
it is easier to plan an implementation timetable.
Post-implementation
factors also have to be taken into consideration. When purchasing a package
solution and outsourcing the implementation, the customer is, in effect, shifting
several aspects of risk. Generally the subject of risk is associated only with
the implementation. Yet, in the long run, taking a longer view, customers are
also exempting themselves from the task of maintenance, effectively placing
the responsibility and cost for keeping abreast of technological advancement
and market trends on the vendor. Though leaving the vendor responsible for technological
advancement can be a risk in itself, the buyer's risk is far reduced.
These
factors, combined with the fact that the majority of resources engaged for implementation
are outsourced, makes packaged solutions easier to budget for and appear cheaper
on paper. The level of control, accountability and reduced risk makes for an
attractive proposition when compared with custom development. Generally, it
is difficult if not near impossible to enjoy all of these benefits when it comes
to building custom applications, in-house or outsourced.
However,
for all these positives, packaged solutions also have their drawbacks.
The
most well known of these is that packaged solutions are never exactly tailored
to meet all customer needs. Additionally, customers almost always end up purchasing
and paying for more functionality than they actually need. As a result they
often complain that their total cost of ownership (TCO) is higher than
expected for the smaller portion of functionality they actually use.
For
the most part these complaints are valid and expected. Packaged solutions, by
definition, strive to be a "one-size-fits-all" or an "off-the-peg" solution.
They are, therefore, designed to fit the broadest set of requirements and are
void of industry or sector specific functionality. Obtaining these enhancements
often drives up cost significantly, resulting in a cost to functionality ratio
that is difficult to justify. However, in some instances where vendors recognize
that an enhancement will have broad appeal in their customer base, they will
include the feature or functionality in the implementation at a much-reduced
cost. This is, however, rare. Customers with shallow pockets soon learn that
they are at the mercy of the vendor when it comes to specialist requests.
It
is then that customers wish they had taken the build route. They start to source
alternative packaged solutions or reconsider the build option with the intention
of integrating the new solution to their existing system. Integration is, however,
not always possible and often carries a heavy price tag especially when proprietary
technologies, such as electronic data interchange (EDI), are involved.
Integration also has the nasty side effect of increasing the costs of future
upgrades, since changes in any part of a system may cause the integration layer
to no longer operate as initially designed. A simple addition or modification
to a field may cause exceptions and even result in data corruption. The total
cost of ownership is, therefore, forced higher, flexibility is reduced and often
it may have been a cheaper long-term decision to have the main vendor develop
the special requirements from the onset.
Understandably,
this situation is undesirable from the customers' perspective and often leads
to tensions in the relationship or worse, a general disillusionment with ERP
as a whole.
The
customer expects to purchase a packaged solution free from the constraints of
the vendor and retain the ability to develop deep industry or sector specific
functionality that will improve their overall level of execution to better customer
relations, increase productivity and profitability—all the items for which they
bought ERP in the first place.
Build (Custom Application)
In
the face of advanced packaged solutions, support for building custom applications
has waned but did not die a silent death, and it is, therefore, still possible
to find organizations that prefer to build their applications. When asked why
they prefer this route, the answer most commonly given is, "When we surveyed
the market, we did not find a packaged solution that met all of our business
requirements or could integrate to the existing systems."
The
key advantage of the build option is that organizations can create applications
that match 100 percent of the nuances particular to their business. Most custom
applications are also more closely aligned with user requirements, and therefore
increase usability, reduce training, and generally promote the user experience
and level of satisfaction with the system.
The
additional advantage is that organizations only develop the functionality they
require and are, therefore, not paying for features or enhancements for which
they do not have a use. This comes with the added benefit of not having to pay
ongoing annual license fees (ALF).
Object-orientated
development techniques that enable a building block approach to creating applications
have significantly reduced development time-scales. These factors, combined
with cost-effective, off-shore coding shops, have in many cases taken the shine
off packaged solutions. The result being that the build option is once again
enjoying a rise in popularity.
Now,
for the bad news. As mentioned in the previous section, it is difficult to accurately
place a timeline on custom development initiatives. Estimation of project duration
and costs is, therefore, often speculative. Functionality must be built from
scratch, and project scope and process modeling need to be completed and understood
before development begins. Getting either of these wrong may result in significant
overruns to timelines and budgets.
Organizations
on the build route also assume the risks of implementation, maintenance, and
have the responsibility for keeping abreast of technological advancement and
market trends. Failing to do the latter may often result in the custom system
being rendered inept from technical and business perspectives. When this happens,
the result is often a scrapping of millions of dollars in labor in favor of
a packaged solution that can be quickly implemented in order to avoid market
fallout.
So
the argument for and against either option is "six of one, half a dozen of the
other". Both routes offer great benefits, but without any ability to reduce
or eliminate their negative qualities.
What
customers need is the ability to leverage the pros of both build and buy options
while being able to avoid the negative qualities. They need something in between.
Somewhere In Between
Does
such a place really exist?
Yes,
new technologies have emerged that are widely considered to be sufficiently
mature as technology platforms that can be used for development and solving
business problems. These technologies include
- Extensible
mark-up language (XML)
- Managed code
realized in Sun J2EE and Microsoft .NET
- Component architectures
Leading
vendors of packaged solutions have already incorporated these key technologies
into their product offerings, resulting in what can be described as a system
and platform providing the best of both the build or buy strategies. Ironically,
the drive behind providing customers with this choice has not been due to the
problems described in previous sections. Instead, the driver has come from the
customers' demand for collaborative commerce (c-commerce).
C-commerce
involves collaborative, electronically-enabled, business integration among an
organization's internal personnel, business partners, and customers throughout
a trading community. The trading community could be an industry, industry segment,
supply chain, or supply event segment.
C-commerce
is made possible by means of ERP II, which is the next iteration in the evolution
of resource-planning systems. ERP II adapts ERP functionality, technology, and
architecture to enable the deployment and interoperation of enterprise applications
both internal and external to the virtual boundaries of the enterprise network.
The
demand for "something in between" combined with the new environmental requirements
and demands of c-commerce has had the following effect on vendors. It has made
them aware that it is impossible for any single ERP vendor to develop packaged
solutions that cater to the thousands of imaginable business applications that
will deliver deep industry specific functionality in all vertical industries
while continuing to assimilate applications and functionality in the core applications.
However,
in order for vendors to qualify for entry to the ERP II arena, they are required
to provide customers with a way to create what many call "next generation" applications.
These factors demand change to the functionality, architecture, and data of
resource planning systems to accommodate the characteristics of "next generation"
applications that will
- Make
extensive use of existing enterprise applications and business logic as a
business process infrastructure.
- Make significant
use of freely available, open, and standards based integration and connectivity
resources.
- Have a small
technological footprint relative to the core technology stack or core applications.
Resource
planning systems that enable ERP II deployment capabilities are finally helping
customers to realize the "somewhere in between." They give customers the basic
functionality for which ERP is known, while enabling an extension or expansion
in functionality from this position. Furthermore, they give the enterprise the
agility and flexibility to develop (build) or choose other best-of-breed vendors
(buy), and so craft a system that can be easily adapted to business requirements
and next generation applications.
Conclusion
ERP
II helps customers drive business change and innovation while reducing IT costs
and complexities.
Going
forward, companies that incorporate an ERP II strategy will be better positioned
to focus on their vertical strategies through increased, deep, industry specific
functionality or any unique functionality to the organization. As momentum grows,
traditional core functionality will increasingly be viewed as a commodity.
Next
generation applications will undoubtedly become nothing less than the future
of enterprise software. As we move into this era, we will be increasingly forced
to rethink some of our conventional wisdoms and traditional approaches to application
development. From the limited scope of this article, perhaps the most important
of these is the "80/20 principle".
This
principle advocates that nearly 80 percent of any custom development effort
is focused on overcoming problems related to core technologies, data access,
security, query, and user interface. The remaining 20 percent is spent on actually
developing the business end of the solution. These new technologies and ERP
II compliant systems reverse this principle so that 80 percent of the development
time can be focused on developing the business solution.
The
result should be custom business solutions built on the business logic inherent
to packaged solutions that more accurately meet both the business and user requirements.
This
article has been sponsored
by SYSPRO
About
the Author
Sean
Wheller is an author, management consultant and the president of enbaya,
a consulting firm that assists hi-tech businesses as they chart a course and
get underway with new initiatives-products, markets, partnerships, and entire
businesses. Wheller is the author of the book "SYSPRO e.net
solutions - The Definitive Guide" which is available from SYSPRO. Over the past
fifteen years, he has been a consultant to leading European, American, Middle
Eastern, and African based information services and software firms. Prior to
founding enbaya, Sean held the position of CEO at MediaOneIT.
Currently, his clients include Lucent, Avaya, Nortel, IBM, Comverse, SYSPRO,
and numerous early stage technology firms.
He
can be reached at sean@enbaya.co.za