A Methodology For Developing Viable And Cost Effective Customer
Relationship Management Systems
Cyrus Azani,
NGC Information and Technical Solutions Division; Reza
Khorramshahgol, Kogod School
ABSTRACT:
The paper focuses on developing and maintaining viable, long lasting, and cost-effective customer relationship management CRM systems via modular network of open architectures. After a brief discussion of CRM and open systems concepts, we propose an integrated methodology for developing a sustainable, upgradeable, and interoperable strategic CRM system. By following the proposed methodology, an organization can develop CRM systems characterized by lower total cost of ownership, shorter development cycle time, and better capability to adapt to evolving requirements and technologies.
1. Introduction
The knowledge age has resulted in massive business and technological paradigm shifts. The physical boundaries among countries and organizations have lost their significance. Globalization of economies, technologies, and markets has become a pervasive reality. Knowledge has become a publicly available and abundant good. Technologies such as the Internet are reshaping the norms of individual, organization, and community behavior. After the telephony and TV, the internet has had the greatest impact on all aspects of our lives. With the rapid spread and explosive success of the Internet and the World Wide Web, e-commerce was born and there was an abrupt collapse of all borders of the markets. New industries were created and various business models were devised to cope with online commerce in global markets. In the midst of all these evolutions, there was one force that came out to be the top winner and the most powerful: the customer. An organization’s customers became the main pillar of its business and customer care became the center of all organizational activities and efforts. Meanwhile, many businesses realized that to establish a one-to-one relationship with each customer and to create loyalty through such relationship was the most fundamental business activity that could have a significant impact on an organization’s survival and growth in a highly competitive, global market.
CRM is the strategy and the infrastructure for creating customer loyalty and, ultimately, establishing and maintaining a long lasting relationship with customers. To achieve CRM objectives, CRM technologies capitalize greatly on data warehousing, data mining and knowledge management. Consequently, even though CRM implementation is a major strategic decision and not a technological solution, it can be a highly capital-intensive endeavor due to heavy investments in CRM technologies. Regardless of technologies used for CRM, system integration is almost always the initial step for its implementation. Integration and interoperability among all the front office as well as back-office information systems including legacy systems is essential so that a single version of the truth e.g., about each customer can be obtained. Such information is much needed for effective and efficient CRM.
However, traditional system development strategies may no longer be appropriate tools for developing dynamic and evolving CRM applications. These strategies assume that all the requirements for a CRM system are known in the beginning of the development process and can be frozen in time or are less likely to change. The traditional approaches also assume that various technologies used for constructing the CRM systems are static and are subject to minor changes. Moreover, the traditional development strategies are slow and result in excessive total system life cycle costs.
Current business and technology paradigms demand more effective CRM development approaches. As a result of globalization of markets and the emergence of virtual organizations the CRM systems are subject to evolving needs of the customers and are subject to growing system requirements. Because of global competition and globalization of technical know-how the organization’s competitors are continually upgrading their systems to provide ever-increasing services to their customers and be able to improve their market share quickly and more effectively.
Many CRM vendors claim to provide a comprehensive solution to an organization’s CRM needs. However, such claims are far from reality and eventually an organization ends up acquiring various technologies from different vendors to meet CRM requirements. As a result, a firm ends up with a mix of various incompatible products. In such a heterogeneous environment there is a profound need for innovative and integrated development strategies that are capable to address the new business and technological paradigms, and develop CRM systems that are long lasting, evolving, and have the capability to quickly and affordably adapt to technological changes and growing needs. In addition, a CRM strategy that avoids vendor lock-in is also highly desirable so that an organization can chose the best products from different vendors to meet its strategic objectives.
The methodology proposed in this paper is based on open systems strategy. It provides a method for building an evolving and upgradeable CRM system. However, we do not recommend this methodology as a panacea for all conditions and cases, or a substitute for traditional system development methodologies. We consider it an effective supplement that makes such methodologies/strategies more in tuned with current business and technology realities.
2. The
CRM Concept And Technologies
As an analogy to the middleware used in client/server computing which connects two pieces of an application, CRM could also be regarded as the middleware i.e., the glue between a business and its customers. By forming customer profiles, CRM aims at establishing a two-way dialogue between an organization and its customers so that products, services and customer support can be customized to fit the individual needs of the customers. In a way, as opposed to traditional mass product, one size fits all marketing strategy, CRM aims for mass customization, one size fits one strategy (Burnett, 2001; Brown, 2000; Rigby 2002). The ultimate goal in CRM is to create customer loyalty and a long lasting relationship (Hanson, 2005; Peppers, 1999). The Internet-based CRM is called eCRM (Greenberg, 2001). Thus eCRM can be considered as online CRM. CRM is a strategic approach that, if implemented appropriately, can have a great impact on a firm’s profitability. Besides profitability and creating customer loyalty, one can identify the following as other benefits of CRM (Swift, 2001): customer retention, customer acquisition, channel optimization, risk management, fraud prevention, demand forecasting, and price optimization.
The following is a brief listing of various CRM technologies:
First and
foremost CRM technologies are the Internet and WWW (Comer, 2001). A well-designed web-based call center is also
instrumental for providing quality customer support and service (Day, 2000). In addition, various intelligent agents can
play a significant role in CRM and can assist greatly in various aspects of CRM
such as personalization and knowledge management (
As mentioned
earlier, integrating the legacy systems and various stovepipe information
systems throughout the organization is absolutely essential so that a single
view of customers and also a single version of truth about each customer can be
obtained on an any-time, any-place basis (Swift,
2001). Consequently, various middleware
technologies are needed to integrate such systems and to glue pieces of an
application that may reside on different clients and servers.
On line
analytical processing OLAP and data mining technologies are of utmost
importance in CRM and can provide trends, forecasts, and correlations that
enable a firm to gain invaluable wisdom that can direct future CRM and
marketing activities Berry, 2000.
Knowledge management plays a fundamental role in CRM (Mattison, 1999).
Last but not least are the technologies that deal with security and
privacy. Obviously, privacy and security
are the foundations for creating customer trust and loyalty (Hassler, 2001).
3. The
Open System Concept
An open system is a system that through permeable boundaries and standardized interfaces continually exchanges material, information, and energy with other systems within its environment (Azani, 2001). The open system OS strategy is an integrated business and technical strategy to 1 choose commercially supported specifications and standards for selected system interfaces external, internal, functional, and physical, products, practices, and tools, and 2 build systems based on modular hardware and software design.
Figure
1: Open System Characteristics
As seen in Figure 1, an OS design approach
partitions a system into self-contained, functionally cohesive,
interchangeable, and adaptable elements to enable ease of change, achieve
technology transparency and mitigate risk of obsolescence. It uses rigorous and
disciplined definitions of interfaces and where appropriate, define
the key interfaces within a system by widely supported standards including
interface standards, protocols, and data interchange language and standards
that are published and maintained by recognized standards organizations. An
interface is designated as key interface when the technology turnover is rapid and design risk is high on either side
of the interface, and/or the system modules on one or both sides of the
interface exhibit a high failure rate, are very expensive, or require
interoperability (Azani & Khoramshahgol,
2005).
The
OS strategy will enable rapid acquisition with demonstrated technology,
evolutionary and conventional development, interoperability, life-cycle
supportability, and incremental system upgrade without redesign of entire
system or large portions thereof. It also enable continued
access to cutting edge technologies and products from multiple sources, and
prevents systems from being locked into proprietary technology.
As a technical strategy, the OS strategy assesses the feasibility of using widely supported commercial interface standards in developing systems. Selection of commercial specifications and standards in an open system should be based on:
Ø Whether the standards are developed and adopted by consensus based standards bodies;
Ø The degree to which the standards are accepted in the commercial market place;
Ø Extensive market research to evaluate the short and long term availability of products build to such standards;
Ø A disciplined systems engineering process that evaluates the cost and performance tradeoffs of such standards;
Ø Supportability and upgrade potential within defined cost constraint; and
Ø Allowance for continued access to technological innovation supported by many customers and a broad industrial base.
As a business strategy, the OS strategy implementation will enable organizations to leverage the commercial sector investment in new technology and products, build and upgrade systems more quickly and affordably, and be able to enhance life-cycle supportability.
As shown in Figure 2, openness is relative and some systems may be more open than others based on market acceptance of open standards, and the extent to which the key interfaces in a system use such standards. In most cases, practical openness may be the best that OS designers could achieve.
Figure
2: Degrees Of Openness
The OS approach can play an important role in defining and evaluating the feasibility of alternative CRM concepts and to provide a basis for assessing the relative merits i.e. advantages and disadvantages, degree of risk of these concepts. Initiating an OS approach early in the CRM concept exploration phase is key to realization of full benefits of an OS strategy.
4. The
Methodology
The proposed methodology is an integrated and iterative process consisting of seven major phases. These phases/steps have been configured and constructed based on sound systems engineering, consulting and business experiences of the authors, and examination of reasons for CRM project failures.
Figure
3: The Proposed Methodology
The
detailed purpose and order of use of the 7 phases used within this process is influenced
by multiple factors such as the urgency of developing a new CRM system or
modernizing the existing one, the maturity of technologies required, and other
organisational and technical considerations, each of which may vary during the
life of a system. The proposed
methodology is applicable to new as well as legacy CRM systems and should be
implemented by
an
“Integrated Product/Process Development IPPD” team with appropriate
knowledge and skills. The IPPD team must include all of the stakeholders
involved in the acquisition and employment of the CRM system. It should at a
minimum include those who generate requirements, design, build, test, operate and maintain the system for its lifetime. The
actual make up of a particular IPPD team is the responsibility of the
organization executives.
Figure 4 depicts the major OS related activities that must be undertaken as a prerequisite in using the proposed methodology. The IPPD team should begin its work by gathering and analyzing all the lessons learned by previous CRM projects or the industry to make a more informed decision at each of the stages/phases within the process. The team must also establish a process for continuous market research. Market research and analysis is needed to gather in-depth information about customer needs, identify consensus or de facto interface standards, assess the breadth of compliant commercial products, and partition the system into modules based on these interfaces.
Figure
4: Initial Considerations
4.1. Phase
1: Study Existing CRM System And Explore Alternative
Concepts
Initiating an OS strategy early in the development process is the key to realization of its full benefits. During this phase, there are four activities that will drive the CRM system development:
1.
Identify
customers’ needs
2.
Explore
alternative concepts
3.
Assess
technologies
4.
Propose
viable solutions and develop strategies
4.1.1. Identify Customers’ Needs
The following operational/performance characteristics are all required by CRM. Such characteristics make CRM the best candidate for the application of open systems (Azani & Flowers, 2005):
Ø There is a need for seamless and high-speed digital information exchange within the organization and between the customer and the organization.
Ø The nature of customers’ expectation is unknown and/or it is continuously changing.
Ø There is an urgent need for integration and interoperability of all information systems throughout the organization.
Ø There is no single technology proven to be the solution for all CRM problems.
Ø There is a need to quickly reconfigure systems in response to emerging needs.
Ø There is an urgent need for receiving and disseminating high quality information in real time.
Ø There is a need for application of an evolutionary acquisition strategy to add and facilitate the incorporation of future capabilities and advanced technologies.
Ø There is a call for development of architectures that must comply with predefined interface standards.
Ø There is a call for optimizing cost-effective commonality of hardware, software, and support systems; continuing access to commercial technology/products from multiple CRM vendors.
Ø There is a need for application of modular, reusable, portable, extensible, and non-proprietary software.
4.1.2. Explore Alternative Concepts
Various fact-finding techniques e.g., online methods, surveys, etc. are used
to gather information about the needs of the users of CRM system. In addition, an evaluation of the weakness
and strengths of the current CRM system should also be performed. Generally
speaking, the user needs are expressed in requirement documents as capabilities
rather than technical solutions and specifications. The user needs are then
explored by a series of competitive, parallel, short-term concept studies
focused on defining and evaluating the feasibility of alternative concepts and
to provide a basis for assessing the relative merits i.e., advantages and
disadvantages, degree of risk, etc. of these concepts.
For legacy CRM systems, modernization plans should confirm that alternatives that are compatible with OS approach demonstrate priority standing. Modernization plans that have limited opportunity for an OS approach should only be considered based on rigorous and detailed lifecycle cost analysis.
4.1.3. Assess CRM Technologies
No new system must be developed based on unproven technologies. A CRM project will be initiated after conducting a technology readiness assessment to examine concepts, technology requirements, and demonstrated technology capabilities to determine technological maturity.
4.1.4. Propose Viable Solutions And Develop CRM
Strategies
In general, the overarching goal of using an OS approach is to develop the best overall value solution over the system's life cycle that meets the user's and customers operational requirements. The fulfillment of this goal is dependent upon an effective assessment of the feasibility of using widely-supported commercial interface standards for the proposed system. Making a business case for use of open systems via a dynamic cost-estimating model will facilitate such feasibility. Cost models must consider differences between alternative open and closed systems. Since CRM technologies change rapidly, a dynamic cost estimating model that incorporates the cost impacts of future technology insertions and accesses to multiple sources of supply for the life of CRM system must be considered. Open systems may require additional up front funding for CRM implementation, but should result in lower sustainment costs commercial supply support, technology refresh or insertion, system upgrade for an overall lower total cost of ownership.
4.1.4.1. Acquisition Strategy
An OS approach to acquisition will provide valuable information for
determining the acquisition, support, and technology strategies for the CRM
program. It will also lay the groundwork
for a successful system design and implementation. Particularly, in the mix-and-match
environment in which CRM operates where different technologies from various
vendors must be interconnected, we need to use the OS approach as an acquisition
strategy to establish or maintain access to competitive suppliers for critical
areas at the system, subsystem, and component levels.
Any program can follow two approaches in developing a system:
evolutionary or a single step to full capability. An evolutionary approach is preferred for
CRM. Evolutionary acquisition is an
approach that fields an operationally useful and supportable capability in as
short a time as possible. This approach
is particularly useful if software is a key component of the system, and the
software is required for the system to achieve its intended mission. Evolutionary acquisition delivers an initial
capability with the explicit intent of delivering improved or updated
capability in the future.
The following OS objectives are all
equally applicable to CRM:
Ø
Technology
management: The objective is to ensure affordable modernization throughout the
system life cycle via continued access to latest technologies available in the
commercial market place.
Ø
Lifecycle
cost management: The objective is to reduce the total ownership cost via
continued access to commercial open products produced by multiple supplies and
lowering risks associated with relying on a single source.
Ø
Affordable
interoperability. The objective is to ensure that the resulting system will be
fully interoperable with all the systems with which it must interface without
major modification of existing components.
Ø Integrability. The objective is to ensure that the system will provide the ability to quickly and affordably interconnect and assemble existing systems, subsystems, and components as needed.
Ø Adaptability: The objective is a system design sufficiently robust to enable effective adjustment to changes.
Ø
Risk Management: The objective is to isolate the
risk areas in such a way as to allow multiple design solutions to mitigate the
risks associated with technology obsolescence and minimize reliance on a single
source of supply with proprietary products i.e., vendor lock-in. We need a risk management plan to identify and control
those potential events that could negatively affect the performance, schedule,
or cost associated with the system development.
4.1.4.2. Support Strategy
CRM project managers should also develop
a system support plan that addresses non-developmental and/or commercial items
whose design is not controlled by the organization, and the performance and
interface specifications of which may be unilaterally changed by the suppliers.
We also need to evaluate the risk and impacts on total cost of ownership
if products with closed interfaces are to be acquired.
4.1.4.3. Risk Management Plan
The risk management plan should address
the risk areas that are managed by using an OS approach as well as the risks
associated with using commercial standards. In general, the OS approach is a
strategy for managing the risks associated with reliance on proprietary source
of supply and technology obsolescence.
However, OS designs are not risk free.
Risk areas specific to open systems that a risk management plan should
address include:
Ø
Reliance on
commercial software over which the organization has no control. Not only might a vendor unilaterally change
the performance characteristics of its software system but it may also change
or extend the interface specification. In addition, the vendor may at any time
stop supporting the software or replace it with a newer version that may not be
backward compatible. Mitigate this risk
area through use of standards that provide the widest commercial base and
development of a thorough conformance management process.
Ø
Reliance on standards
that organization has no control and may change. These changes may result in
conflict for a particular interface.
Mitigate this risk through involvement with standards development and a
conformance management process that emphasizes standards conformance as well as
product conformance and compatibility.
Ø
Selection of
the wrong standards. Mitigate through
careful market analysis. Where the
choice is close between competing standards, mitigate through assessment of
relative strengths of competition and design consideration of the consequences
of future upgrade to alternative standards.
4.2. Phase
2: Develop The Initial System Architecture
At this phase, the building blocks of the CRM system architecture are put together. The actual entry point depends on the maturity of the technologies, validated requirements including urgency of need, and affordability. For a legacy CRM system, system architecture begins by gathering information on the As-IS architecture and performing the essential mapping of services and interfaces to known functions and capabilities. Also, for a legacy system, one needs to review the design specifications, interface control documents, functional specifications, other respective systems/subsystems that must be interfaced, and known standards profiles for the system to make a sound decision.
To develop system architecture we need to decompose the system into a small number of system building blocks using reference models and interface management. We use modularity principles and the systems engineering process with greater reliance on interface control to support functional partitioning. Modularity principles are used to facilitate the replacement of specific subsystems and components without impacting other parts of the system. By partitioning a system into modules we will be able to develop a flexible system, reduce program risk, ensure operational supportability, assure affordability, and demonstrate system integration, interoperability, and utility. We also use functional partitioning and modular design to enhance understanding of interfaces and identify those that have significant impact on total ownership cost, and on adding new capabilities and technologies.
We also need to prototype the system,
subsystems, and components in order to 1 demonstrate the integration of the
system using the proposed modular decomposition and 2 demonstrate standards and
standards-compliant products and ensure that potential interface standards and
specifications will achieve required system performance.
Figure 5: Architectural Considerations
The
open architecture, while remaining viable for a set period of time, evolves
over time. It is completed at a high level as part of the functional
baseline first and its preliminary design and development will be based on a
draft allocated baseline, including draft interface control drawings and
documents for internal and external interfaces. As we move from reference model to architecture, we map
out system functions, and organize the interfaces of these functions into a
“skeleton” of a system. This
skeleton, when complete, will support system modularity. Once the architecture
is defined, the functions associated with the system modules can be managed
using the traditional systems engineering process.
4.3. Phase
3: Identify The Key Interfaces
At this stage we need to identify a
complete set of functions, services, and interfaces new or additional ones that
a new or existing CRM system needs, and perform comparative and tradeoff
analysis to group them into key and non-key categories.
Key system interfaces in Figure 5
include interfaces functional or physical connection between systems,
subsystems, or components where the
technology turnover is rapid and design risk is high on either side of the
interface, and the system elements on one or both sides of the interface
exhibit a high failure rate or are very expensive. Since CRM technologies change rapidly and
many new technologies are introduced annually, identifying key interfaces
have significant impact on the ability to add new capabilities, insert new
technologies, achieve commonality and interoperability, and replace items with
high replacement frequency and cost. As mentioned earlier, reference models are
perhaps the best means for identifying key interfaces. Use reference models to:
Ø
Identify
rapidly changing technologies applicable to the proposed concepts,
Ø
Identify
proposed subsystems which are likely to grow or evolve over each proposed
concept’s life,
Ø
Identify
high lifecycle cost drivers,
Ø
Identify
interfaces likely to be affected,
Ø
Establish a
list of key interfaces
4.4. Phase
4: Assess The Feasibility Of Using Open Standards
After the list of key interfaces are identified the IPPD team should gather information through market research to assess the feasibility of using well-defined, widely used, and consensus based standards for each key interface. The key interfaces should be examined to insure that the use of an open standard is both feasible and appropriate based on performance and business objectives of CRM. There are significant advantages to using open interface standards, however we should use them only if it makes sense with the context of the performance and business objectives of the particular CRM system.
Figure
6: Key Interface Considerations
In some cases, it will not be possible or prudent to use an open interface standard but the benefits gained from the isolation of the function for future change may far outweigh any disadvantage of using a closed proprietary interface standard. If the answer is, “no” the team should continue to look for future opportunities to take advantage of open interface standards.
Following are some of the reasons that a CRM program should use open standards to define key interfaces:
Ø High degree of dependency on rapidly evolving technologies.
Ø The intensity and magnitude of risks associated to a proprietary interface standard.
Ø Need for minimizing integration risks for seamless functioning of CRM.
Ø Need for design flexibility, modularity, and interface control
Once the team identifies all of their selected key modules/interfaces that must be defined by open standards, they have specified their level of openness.
4.5. Phase 5: Establish The
Levels Of Openness And Select Appropriate Standards
4.5.1. Level of Openness
The level of openness is the level e.g., system, subsystem or component at and above which the user aspires to maintain control over the key interfaces and would like these interfaces to be defined by widely-used and consensus based standards (Azani & Khoramshahgol, 2005). To establish the desired level of openness, one must conduct a survey on availability of open standards for selected key interfaces and assess the impact of a chosen level of openness on long-term viability and affordability of the CRM system. The level of openness may change over time as new standards are developed and adopted by recognized standards organizations and as the system evolves. We need to anticipate how this level may change over time and assess the impact of a given level of openness on long-term viability and affordability of the system. Also, we need to establish initial level of openness objectives consistent with interoperability, integrability, upgradeability, affordability objectives, and industry practice based on market research.
Figure 7: Level Of
Openness Considerations
The type and the number of key interfaces in a system, availability of
mature and widely accepted standards/products developed/built with such interfaces,
and the organization’s overall acquisition and supportability strategy
will influence the decisions for establishing a desired level of openness for a
CRM system/subsystem/component. There most likely will be multiple levels of
openness in any given system because of the variety of subsystems and
components used in the system. The CRM development team must review and update the desired levels of openness
to be consistent with concept developments and continued market survey results.
The team must also ensure that the level chosen to define the open interfaces
is at a level supported by the industry and consistent with supportability
planning. Remember that below this level the contractor is permitted to
use its best, perhaps proprietary practices to improve or discriminate its
product in the marketplace.
The level of openness changes as requirements evolve and influences the extent to which the buyer can use multiple suppliers, insert new technology, accomplish shop repair maintenance, and assign the control on design, interfaces, repair, and implementation to the contractor. Defining the level of openness too low may limit efficient technology insertion, while defining the level too high may lead to the use of proprietary interfaces for major system components resulting in limited supplier support. Advances in technology increases in system processing power and communications capacity are allowing system engineers to build systems with fewer instances where system resources e.g., processors and communications capacity are dedicated to particular applications to ensure real-time, fault tolerance services over distributed, fully connected systems. Instead, system resources are being allocated dynamically such as in peer-to-peer computing which results in shifting away from federated systems to more integrated systems. As a result, the desired level of openness move higher away from lower level interfaces tied to application-specific components.
4.5.2. Selection of Standards
The results of the on-going market
research are used to identify and track technology and market trends for
consensus and de facto interface
standards. We use the findings of the market research to identify specific
commercial and or non-developmental products hardware and software that are
compliant with such standards for possible use in the proposed CRM system. The
preference is always on use of open standards those that are certified by
recognized standards organizations and are widely used by the industry first,
then de-facto standards, and finally proprietary and government standards.
Evaluate the market acceptance and maturity of potential standards to determine
if they support CRM mission requirements and meet open systems objectives for
affordable system evolution. Selected standards should provide access to
non-developmental items and commercial items that are available from multiple
sources. Assess the impacts of new technologies to determine likely evolutions
of standards. If emerging standards are
used, then the organization should consider participating in appropriate
standards bodies to ensure standards definitions meet your organizational and
CRM requirements. We may ask the following questions when selecting standards:
Ø
To what
degrees are the candidate standards based on mature technology and are
currently used in production?
Ø
Are there
current products available, built to the candidate standards?
Ø
Are several
vendors complying fully with the candidate standards?
Ø
Do the
candidate standards have a defined test suite or conformance criteria to
eliminate the time and cost of testing?
Ø
Are the
candidate standards produced and maintained by a reputable accredited standards
organization?
Ø
Are the
extensions to the standards by suppliers likely to make the system dependent on
a single source of supply throughout the lifecycle?
Ø
Are the
standards selected compatible with one another? Do they overlap?
After the standards are selected we need to prepare system profiles. A system profile contains all of the individual standards, and interface requirements selected for a system. The profile also lists for every interface standard, the tailoring instructions and the selected optional extensions if applicable. Although the system profile references the interface standards at the desired levels of openness, the interfaces below the specified level may also be designated by open standards if the provider so desires.
4.6. Phase 6: Prepare Technology Transition And Conformance Management Plans
Technology Transition Plans. The CRM development team should also include,
in their acquisition planning documents, their blueprint for dealing with the
planned upgrades or technology insertion. It should develop a strategy for interface upgrade and technology insertion as soon
as the system architecture is finalized.
If newer versions of subsystems are to be “cut-in,” then the
capability to test for standards compliance, compatibility, interoperability,
and mission effectiveness must be planned.
Similar concerns apply to in-service upgrades. Where appropriate, the
program office should forecast and budget for in-service upgrades. This
plan can be tracked throughout the life of the program at program reviews and
milestone reviews.
Consistent Conformance
Management. The CRM project team must also devise test
plans to ensure conformance of selected commercial software and
non-developmental software to appropriate interface definitions especially
widely used consensus i.e., open standards.
In other words, it is important to check the availability of application
programming interfaces APIs for proprietary CRM software and the conformance of
APIs to open standards. In addition
compatibility tests must be performed to ensure system modules interface and
function together properly. We need to
test to determine if conformant modules from different CRM software vendors
will work seamlessly. We should also
address verification of the profiles to assure they fully meet requirements.
4.7. Phase
7: Finalize The System architecture, Document The OS
Approach And Report On The Progress
Where appropriate, the CRM project
leader need to challenge or tradeoff operational requirements that preclude use
of open standards and open standards-compliant software. The CRM team should also remember that the
open system design is one of the fundamental criteria by which organization
executives decide whether or not commit the organization to full development of
a new CRM system. The team must also communicate and seek early resolution
before problems become significant issues.
The progress report to executives may
include information on:
Ø
Risk
management processes that address open systems concerns
Ø
Interface
management, including identification, definition, and control of key interfaces
Ø
Technical
and open system architectures
Ø
Identification
of interface standards and specifications
Ø
System
profiles
Ø
Open system
prototypes
Include in your system test plan the verification procedures and criteria for
conformance testing of both standards and conforming software products. Verify the functional and performance
requirements of the CRM system have been met. CRM project leaders should
also validate the openness of system, subsystems,
and/or components at the levels specified. Following are examples of means for
fulfilling this objective:
Ø
If contractors or
consultant used, require contractors/consultants to certify that they have used
widely accepted consensus standards for key interfaces at and above the
specified levels of openness.
Ø
Performing conformance and compatibility testing at and above the specified levels of openness.
Ø
Asking independent
test facilities to verify the use of open standards at and above the specified
levels of openness.
Ø
Developing innovative
means such as indices e.g., a color-coded scheme, percentage, or numerical
value to determine the extent of openness of system/subsystems.
Review and revise, if necessary, key
interface identification and definitions.
Continue to select standards and develop interface profiles to complete
the open system architecture. Based on the information gathered redefine
the user needs, modify the acquisition, support, and technology strategies, and
reallocate the modified requirements to the selected modules. The new
requirements associated with future blocks of improvements must also be fed
into the OS implementation process at this stage. For rapidly changing technologies, the CRM development team must delay
implementation decisions choosing of conformant products in order to manage the
risk of parts obsolescence and to provide the most current designs at the time
of production.
The CRM project leaders may use
interface management as a configuration control device and include interface
requirements in component specifications. They should identify conformance
products for most components. Purchase descriptions of all or most components
should be sufficiently complete and contain references to standards. The CRM
project leaders must ensure that alternate sources for purchase is available
for all or most components and they may also decide to participate or support
participation in industry open standards development that is important to their
CRM system.
Conclusion
Customer relationship management CRM/eCRM is perhaps the most important strategic weapon for contemporary businesses. CRM, already a multi-billion dollar industry has been growing rapidly and based on various reports it will continue to grow in the future. Industry experts also indicate that CRM is here to stay. However, not all companies have been successful in CRM development and implementation and there has been many reports of CRM failures. To facilitate CRM implementation and to minimize risk, this paper proposed an integrated development methodology based on modular open architectures. The methodology is a supplement to traditional software development methodologies and if followed properly, it ensures that CRM systems will remain viable and cost effective, and evolve as customer and user requirements and technologies change.
References
Azani, C.H. (2001), “The Test And Evaluation Challenges of Following an Open System Strategy,” The ITEA Journal of Test and Evaluation, Vol. 22, No. 3.
Azani C., Flowers, K. (2005), “Integrating Business and Engineering Strategy Through Modular Open Systems Approach,” Defense AT&L Journal; pp. 37-40.
Azani C., Khorramshahgol, R. (2005), “Management
of Technology Using a Modular Open System Strategy,” Proceedings of the
12th European Concurrent Engineering Conference,
Burnett, K. (2001), The Handbook of Key Customer Relationship
Management. Prentice Hall Inc.,
Comer, D.E. (2001), Computer Networks and Internets, third
edition. Prentice Hall Inc.,
Day, C. (2000),
Greenberg, P. (2001), CRM At The Speed of Light. McGraw Hill,
Hanson, W. (2000), Principles of Internet Marketing.
Hassler,
V. (2001), Security Fundamentals for e-commerce. Artech
House,
Inmon, W. (1996),
Building the Data Warehouse second edition, John Wiley & Sons, Inc.,
Inmon, W., Rudin, K., Buss,
C., Sousa, R. (1999), Data Warehouse Performance. John Wiley & Sons, Inc.,
Inmon, W. (March, 2000), “The Future of Data Warehousing: Alternative Storage,” DM Review, Vol. 10, No. 3; pp. 48 - 51.
Inmon, W., Imhoff, C., Sousa,
R.. (2001),. Corporate Information Factory. John Wiley & Sons, Inc.,
Kimball, R. (1996), The data Warehouse Toolkit.
John Wiley & Sons, Inc.,
Mattison, R. (1999), Web Warehousing and Knowledge Management, McGraw-Hill,
Peppers, D., Rogers, M., Dorf, B..
(1999), One to One Field book.
Rigby, D., Reichheld, F., Schefter, P., (February, 2002), “Avoid the Four Perils of CRM,” Harvard Business Review; pp. 101-109.
Swift, R. (2001), Accelerating Customer Relationship. Prentice Hall Inc.,
Contact the Authors:
Cyrus Azani, Senior
Systems Engineer, NGC Information and Technical Solutions Division, Suite 104, 1851 South Bell Street, Arlington, VA 22202;
Email: cyrus.azani.ctr@osd.mil
Reza Khorramshahgol, Associate Professor, Kogod School of Business, American University, Washington, D.C. 20016; Email: Reza@american.edu