Packaged software customers share similar
customization, integration, enhancement, and
upgrade needs.
Instead of the traditional top-down design
paradigm, PSI starts from gap analysis to
package customization and integration. A
significant portion of PSI is matching problems
to existing solutions.
Packaged software implementations often
involve external consultants, who bring “the
best practice” from implementations for other
customers. The ability to leverage consultants’
past experience is important to a successful PSI.
Packaged software implementations usually are
joint efforts by several organizations: business
users and technical personnel from the customer
(the client company), functional and technical
consultants from the implementation
consultancy, and the software vendor. Inter-
organizational collaboration is far more
challenging than intra-company collaboration in
tradition software development.
Due to the proprietary nature of packaged
software, PSI typically does not use mainstream
IDE (Integrated development environment)
tools. The availability and applicability of
CASE (computer aided software engineering)
tools is very limited.
Due to the limitations and the rigidity of the
software package, certain seemingly-simple
business requirements may be cost prohibitive
or infeasible. As PSI often involves contracts
within a fixed price range, lowering the risk is
given top consideration among the design
choices. Exploring the technical limitations and
possible risk areas occurs as early as in pre-sales
and contract negotiation.
As seen from above, design exploration and
reuse can significantly lower the cost, increase the
quality and reduce the risks in packaged software
implementations. Exploring and reusing past designs
as a methodology is called case-based reasoning
(CBR), defined as a problem solving approach that
solves a new problem by exploring previous
experiences, recalling a similar situation and reusing
information from that situation (Maher and Pu
1997). Despite its significant benefits, CBR is
largely under-utilized in PSI. The biggest challenge
to CBR is to build a rich, up-to-date, explorable and
reusable knowledge base of cases. Next section will
look at how social power can be utilized to build
such a knowledge base.
3 HARNESSING SOCIAL POWER
A new trend on the Web is to utilize the “free brains
and labor out there” among Internet users.
Harnessing social intelligence, i.e. utilizing
individual users’ knowledge and efforts, is one of
the core competencies of “Web 2.0” (O’Reilly,
2005). We see such phenomenon everywhere now:
collaborative spam email filtering, Wikipedia (the
largest encyclopaedia) and even CNN.com’s attempt
to create user contributed news.
The CBR process can potentially harness the
social intelligence from various participants in
packaged software implementations. Besides
documenting and contributing their unique
experiences, individuals can help improve each
others’ designs. Individuals can categorize design
cases along multiple dimensions. Their
categorizations help draw connections between a
new problem situation and existing solutions. Our
fundamental belief is that a diverse, large group of
people can do better than a small team of experts.
Documenting and collaboratively evolving the
cases can be aided by today’s Wiki (Web-based
collaborative editing) systems. Wiki can allow
customers and consultants collaboratively edit the
requirement and design documents. An existing
solution can be updated for a functional
enhancement or compatibility with a new release.
While typical project documents are archived after
the project completion, the documents in a wiki can
evolve after the software implementation goes into
production. A past design can be copied, modified
and reused in a wiki, perhaps by another team, for
another project. The ease of contribution and the
informality lead to success as in Wikipedia.
Searching for cases can be aided by social
tagging. Emerging social tagging systems such as
del.icio.us and flickr.com allow users to assign free-
formed keywords (tags) to any documents, and share
these tags. Any users can browse these tags, or
search for documents tagged with given keywords.
While traditional repositories require objects to be
labeled with metadata at the time of creation or by
privileged administrators, social tagging allows
users label objects not created or owned by them,
and share these labels. In other words, the metadata
is created by data consumers versus data producers.
The connections such drawn between objects and
concepts (tags) are often beyond what is conceived
at the time of creation or by any central indexers.
Exploration of a complex design space can be
made easier if the past design cases are categorized
along multiple perspectives, i.e. classified along
ICEIS 2008 - International Conference on Enterprise Information Systems
344