Customer Relationship Management System

Service Industry

Dennis Guseman , in Encyclopedia of Information Systems, 2003

IV.B. Information Systems to Develop Customer Relationships

Customer relationship management (CRM) is a technological initiative that focuses on building mutually beneficial customer relationships by employing technology that allows marketing, sales, and service to share information and work as a team. CRM systems can be either operational or analytical. Operational CRM systems gather customer information across various channels, such as on-site encounters, phone, Web, and call centers; organizes it; and makes it available to front-line employees so they can better serve customers. Analytical CRM systems analyze the data collected by the operational system to help improve the overall customer satisfaction and profitability of customers individually and collectively.

In general, CRM systems are used to track encounters with consumers and record communications with customers. This information can be used for purposes of segmentation and targeting of products and customer communications. The information gathered can also be used to help retain and develop customers. The CRM system can answer the following questions:

•

Who are the right customers?

•

What is the right customer mix by time period?

•

How do we retain current customers?

IV.B.1. Who Are the Right Customers?

Customers are not equally profitable to serve. Some customers generate more business, are more loyal, and are easier to serve than other customers. Some customers engage in favorable word-of-mouth activities and act like apostles for the company or provide valuable insight into how to better satisfy customers. In general, customers who generate value (produce greater benefit than cost) are the "right" customers.

One of the first uses of a CRM system is to segment and prioritize customers. The segmentation can be based on current profitability of a customer, future potential of a customer, and the potential of the customer to provide valuable referrals. The CRM should provide the necessary information to make these judgments.

IV.B.2. What is the Right Customer Mix By Time Period?

The widely fluctuating nature of demand for many services, along with the inability to inventory services, makes demand management a crucial task for service managers. Managing demand requires having information about the fluctuations in demand and understanding the nature of the demand itself.

Lovelock has suggested asking the following questions to help understand the factors that govern demand for a specific service at a given point in time:

1.

Does the level of demand for the service follow a predictable cycle? If so, is the cycle duration:

•

One day (varies by hour)

•

One week (varies by day)

•

One month (varies by day or by week)

•

One year (varies by month or by season; or reflects annually occurring public holidays)

•

Some other period

2.

What are the underlying causes of these cyclical variations?

•

Employment schedules

•

Billing and tax payment/refund cycles

•

Wage and salary payment dates

•

School hours and vacations

•

Seasonal changes in climate

•

Occurrence of public or religious holidays

•

Natural cycles, such as coastal tides

3.

Do demand levels seem to change randomly? If so, could the underlying causes be:

•

Day-to-day changes in the weather (consider how rain and cold affect the use of indoor and outdoor recreational or entertainment services)

•

Health events whose occurrence cannot be pinpointed (heart attacks and births affect the demand for hospital services)

•

Accidents, acts of God, and certain criminal activities (these require fast response not only from fire, police, and ambulance but also from disaster recovery specialists and insurance firms)

4.

Can demand for a particular service over time be disaggregated by market segment to reflect such components as:

•

Use patterns by a particular type of customer or for a particular purpose?

•

Variations in the net profitability of each completed transaction?

To help in the development of an effective demand management strategy a service manager needs information on:
•

Historical data on the level and composition of demand over time, including responses to changes in price or other marketing variables

•

Forecasts of the level of demand for each major segment under specified conditions

•

Segment-by-segment data to help management evaluate the impact of periodic cycles and random demand fluctuations

•

Good cost data to enable the organization to distinguish between fixed and variable costs and to determine the relative profitability of incremental unit sales to different segments and at different prices

•

In multisite organizations, identification of meaningful variations in the levels and composition of demand on a site-by-site basis

•

Customer attitudes toward queuing under varying conditions

•

Customer opinions on whether the quality of service delivered varies with different levels of capacity utilization.

Information systems need to be designed to provide this information. However, this is not sufficient. Not only is it necessary for a service manager to be able to understand the nature and level of demand, but a service manager needs to manage that demand to yield the maximum amount of revenue.

Customers differ in their ability and willingness to utilize a service at a given time and also vary in the amount of money they are willing to spend. Thus a service manager must consider the yield—the average revenue received per unit of capacity offered for sale—of various strategies. For example, should a hotel accept an advance booking from a tour group at a reduced rate, or should it wait for the potential of receiving a full rate from a business traveler (not knowing for sure whether the business traveler will actually materialize)? Yield management is the strategy of obtaining the best possible yield over time from each available unit of capacity.

Yield management requires the development of mathematical models that analyze past sales data by customer segment, then factors in current market intelligence and considers various marketing efforts to arrive at an ideal customer mix. The ideal customer mix is the percent of business desired from a particular customer segment that will result in the highest revenue generation based on the amount of demand and price sensitivity of each segment.

Yield management involves the following steps:

1.

Identify the principal market segments that might be attracted to the service facility and that are consistent with its capabilities and mission.

2.

Forecast the volumes of business that might be obtained from each segment at specific price levels (through supply-and-demand analysis).

3.

Recommend the "ideal business mix" at each specific point in time in terms of maximizing net revenues, which may not, in fact, be the same as maximizing capacity utilization.

4.

Provide the sales force with specific sales targets on specific dates for each segment. This information may also be useful for planning advertising and related communication efforts.

5.

Providing guidelines for the prices to charge each segment at specific points in time. For some segments, these guidelines should be adhered to rigorously; in other instances, they may simply provide targets for negotiation.

An example of yield management is where an air carrier develops different seat categories for a flight, based on the price and various restrictions placed on a ticket. Thus the most expensive seats could be purchased at the last minute with no restrictions, and the lowest ticket fares would require advance purchase and have many restrictions (Saturday night stay-over, no changes, etc.). To manage the yield, the number of seats in each category could change, based on the number of seats sold, historical ridership patterns, and likelihood of connecting passengers. If analysis shows that business travelers are buying unrestricted tickets earlier than expected, then more seats could be taken from discounted seats and reserved for last-minute bookings.

IV.B.3. How Do We Retain Current Customers?

Once a service firm has established a relationship with a customer, it wants to keep and develop that customer. Research has shown that it is not only less expensive to keep current customers, but current customers who are loyal are more profitable. The longer a customer stays with a business the more profitable they are. So, retaining customers is an important activity. Retaining customers involves more than satisfying customers. A service firm must also establish an effective system for customer complaint and service failure recovery and create bonds with customers.

IV.B.3.a. Customer Complaint and Service Failure Recovery

The high variability in quality that exists for services makes quality control activities important. It also necessitates having good service failure recovery systems in place. Having a system for learning about service failures is important; as many as 90% of customers do not complain when there is a problem, and if there is a problem, consumers are less likely to return to the firm. So, learning of consumer problems and correcting them is important in a firm's efforts to retain customers.

Developing an effective service failure recovery system is basically a matter of first learning about mistakes and then having mechanisms to correct those mistakes. Mistakes in the service delivery process can be identified by:

•

Actively encouraging customers to complain when there is a problem. This requires that customers be aware of complaint mechanisms and have access to them. Multiple methods for voicing complaints need to be developed, including telling the service provider or manager, comment cards, suggestion boxes, toll-free phone numbers, and the Internet.

•

Training contact personnel to identify potential failures. Contact personnel need to question consumers on the level of service received and be perceptive as to when things are not right.

•

Implementing quality control standards and measures. Specific measures need to be taken to ensure quality standards are being met and to alert the appropriate people when they are not met. Information systems play a vital part in monitoring the quality of the service.

Once service failure problems have been identified, steps can be taken to correct the problem. However, more needs to be done than just correcting the problem. The service firm needs to learn from the failure to prevent it from recurring. Service failures themselves need to be analyzed for their root cause. Information systems are needed to track problems so steps can be taken to prevent the problems from recurring.

The role of information systems is to capture customer complaints, analyze complaints for root cause analysis, and empower front-line workers with the information necessary to remedy the problem.

Regardless of the method used by consumers to voice a complaint—in person, via the Internet, phone, or mail—the complaint must be recorded and acted on. Analyzing complaints can provide valuable insight into how to improve the service for all customers. Front-line employees must also be able to access the information system to help them resolve the customer's problem, whether they need to track the status, as in a lost bag for an airline, or provide assistance in the steps and procedures for resolving the problem.

IV.B.3.b. Customer Managers and Creating Customer Bonds

Given the positive impact that retaining customers has on profitability it is wise for service firms to establish customer-managers. Just as product-managers are responsible for overseeing and managing every aspect of a particular brand, a customer-manager is responsible for overseeing and managing the relationship a firm has with a particular customer or customer segment. Some banks have personal bankers for their preferred customers. These personal bankers are the contact person for the customer, and the personal banker will handle all of the customer's needs. This provides a degree of continuity for the customer and ensures that nothing slips through the cracks. The basic job of a customer-manager is to manage and improve the relationship with the customer.

For a customer-manager structure to work the information system has to be organized around customers and not products. The customer-manager has to be able to analyze every aspect of the customer's business with the firm. Having this customer-organized database, rather than a product-organized one, allows the customer-manager to develop bonds or ties with the customer. Berry and Parasuraman have discussed four types of bonds that can be created to retain customers: financial, social, customization, and structural.

IV.B.3.b.i. Financial Bonds

Financial bonds create a financial incentive for the customer to continue doing business with the firm. The most common is a frequency marketing program, such as the airline frequent flier programs or hotel frequent stayer program. Frequent users receive discounted or free services based on the quantity of use. Frequency marketing programs require an information system to accurately track and report the customers' "points." Tracking customer usage becomes the basis for differentiating customer groups based on frequency and volume of usage, which in turn allows a firm to design more targeted programs for its preferred customers.

IV.B.3.b.ii. Social Bonds

Social bonds build on the financial incentives by creating social and interpersonal relationships with the customers. A social bond treats the customer as a client and attempts to understand and serve customers better. Establishing social bonds is especially important for professional services and personal care providers. Social bonds make the service personal by remembering the client's name and past experiences with the firm, by sending cards to commemorate special occasions, and staying in touch to learn of changing needs. This type of relationship requires the service firm to have a transactional database and CRM information systems to record, analyze, and report on all of a customer's dealings with the firm.

IV.B.3.b.iii. Customization Bonds

Customization involves meeting the individual needs of the customer. This means the firm must be capable of learning and remembering from each interaction the customer has with the firm. The information system needs to provide the contact person with the history and preferences of the customer. Armed with this information the firm can provide the exact service the customer desires. For example, Ritz-Carlton Hotel Company's employees are trained to input the likes and dislikes of its regular customers into a customer database. By making the database available to the entire system, a hotel can know in advance the guest's preferences and individualize the service to meet his or her particular needs.

IV.B.3.b.iv. Structural Bonds

Structural bonds are created when the service firm partners with its clients by linking information systems and sharing processes and equipment. For example, Allegiance Healthcare Corporation has created an integrated information system with the hospitals it supplies by linking its ordering, delivery, and billing systems with the customers' systems. Likewise, FedEx also creates structural bonds with its customers when it provides free computers to its customers to allow them to store addresses and shipping data, print mailing labels, and help track packages. These structural bonds tie the customer directly to the service firm and necessitate working closely with customer.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B0122272404001593

CRM – Customer Relationship Management and Analysis

David Nettleton , in Commercial Data Mining, 2014

Integrated CRM Systems

In recent years, companies have invested in CRM systems that become integrated with many of the other business processes in their organizations. The development and installation of this kind of system, for example, unifying a telephone/Internet call center with a data capture system that feeds into a large client database, can be expensive and complex. But the system can retrieve client data from the database and make it available to the sales and customer service staff, which will give them greater success in their commercial dealings with clients. Commercial systems such as Siebel, PeopleSoft, and Genesys are parametrizable standard systems that integrate databases such as Oracle and DB2 with customer service centers, sales force, telemarketing, telesales, and so on. The systems tend to be modular, consisting of a base module with optional modules for report design and generation, wireless communications, and campaign management, among others.

Customer Relationship Management

Call Centers

Some customer service centers offer service twenty-four hours a day, seven days a week, with human operators with agreeable voices and empathy toward clients. Some systems have been completely or partially automated as an alternative to the human operator. Using a voice recognition system based on keywords ("please state your ID number," "please state your city of residence," etc.), the interlocutor is guided with easy-to-reply-to questions.

CRM Application Software

There are many different CRM application software systems currently available, from low-cost personal computer programs to corporate solutions, such as Salesforce (http://www.salesforce.com/assets/pdf/misc/BP_SalesManagers.pdf). There are also "cloud" service solutions, such as Microsoft CRM (http://www.microsoft.com/en-us/dynamics/default.aspx). However, in general, these systems do not contain true data mining functions by default (as do the data mining models presented in this book), and probably require significant customization in order to integrate more advanced capabilities.

The following section briefly runs through the functionality of the Salesforce CRM. According to the vendor, this application has the following main capabilities: decision support (prioritizing customer issues, training for new sales people, forecasting, providing on-demand reports), dashboards (EIS-style interfaces to key indicators with emphasis on use of color codes), trending analysis and benchmarking (using reports and dashboards to show long-term business goals and key performance indicators), lead/opportunity management analysis (classification and qualification of leads), and activity management analysis (ensuring that biggest deals and highest priority customers receive the most attention). According to the vendor, the forecasting capability includes algorithmic modeling and uses probabilities; however, forecasting is dependent on sales people correctly assigning the commercial lead pipeline categories. The sales pipeline has nine major categories: prospecting, qualification, needs analysis, value proposition, identify decision makers, perception analysis, proposal/price quote, negotiation/review, and closed/won. Each category is assigned a default probability of success for the sale. For example, prospecting is assigned 10 percent; identify decision makers, 60 percent; negotiation, 90 percent; and closed/won, 100 percent. Hence, as the pipeline stages progress, the probability of sale success increases.

The overall mission of the application is to provide a system that shows key information at a glance for sales personnel and commercial management. (See http://www.salesforce.com for more details, screenshots, and so on.)

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124166028000133

What Is Customer Centricity?

David Loshin , Abie Reifer , in Using Information to Develop a Culture of Customer Centricity, 2013

Customer Experience as a Corporate Driver of Value

The idea that customer experiences can be managed within the context of a relationship and subsequently automated is not new. Customer Relationship Management (CRM) systems have been in production for a number of years and are intended to comprise a set of strategies intended to help organizations provide scalable customer service for a growing customer community. More specifically, CRM approaches are intended to incorporate systems that would capture customer information regarding the customer. This information can be used to help organizations develop and improve their internal processes so that managers could more easily exchange customers and maintain a relationship with the client.

In reality, though, CRM was also intended to help identify efficiencies in the organization by providing replicable customer support and service functions that scale efficiently, thereby reducing the average cost of customer service on a per-customer basis. In other words, although the initiative was intended to center on the customer, the real focus was to enable the scalability of the services provided to customers.

Curiously, businesses that had historically offered differentiated and personalized customer care began to realize that the CRM strategies they implemented were causing their business to lose what was once a personal touch cherished by their clientele and what likely had differentiated the business from others. In essence, commoditizing their treatment of customers ultimately disenfranchised those very customers that had earlier helped them establish their business.

The recognition that this commoditization of care which diminished the customer relationship has led to considering different strategies designed to engage the customer by focusing on the overall experience in conjunction with the relationship. This approach is less concerned with operational efficiency and instead is intended to let the staff members be more proactive and anticipatory of the customer's needs and expectations. Concentrating on enhancing the customer's overall experience helps to provide the customer with the perception of personalized treatment.

For example, a company may be able to make product suggestions to the different customers based on their earlier purchases.

This is commonly predicted by reviewing the combination of products and/or services a customer has made then comparing those purchases to ones made by others and suggesting products by others having similar interests. Being able to make suggestions of products that compliment the ones already purchased by the customer is an example of a predictive customer-centric approach. Customers often appreciate being informed of related products or services, since that provides them with a sense of individualized and differentiated service.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124105430000019

Developing a Strategy for Integrating Big Data Analytics into the Enterprise

David Loshin , in Big Data Analytics, 2013

4.1 Deciding What, How, and When Big Data Technologies Are Right for You

The adoption of big data technology is reminiscent of other technology adoption cycles in the past. Some examples include the acquisition of customer relationship management (CRM) systems or the desire to use XML for an extremely broad spectrum of data-oriented activities. The issue is that even if these are disruptive methods that have the potential to increase value, the paths by which the techniques and algorithms insinuate themselves are often in ways that might not be completely aligned with the corporate strategy or the corporate culture. This may be because the organization is not equipped to make best use of the technology.

Yet enterprises need to allow experimentation to test-drive new technologies in ways that conform to proper program management and due diligence. For example, implementing a CRM system will not benefit the company until users of the system are satisfied with the quality of the customer data and are properly trained to make best use of customer data to improve customer service and increase sales. In other words, the implementation of the technology must be coupled with a strategy to employ that technology for business benefit.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124173194000041

Securing Cloud Computing Systems

Cem Gurkok , in Computer and Information Security Handbook (Third Edition), 2017

Abstract

Cloud computing is a method of delivering computing resources. Cloud computing services, ranging from data storage and processing to software such as customer relationship management systems, are now available instantly and on demand. In times of financial and economic hardship, this new low-cost ownership model for computing has received lots of attention and is seeing increasing global investment. Generally speaking, cloud computing provides implementation agility, lower capital expenditure, location independence, resource pooling, broad network access, reliability, scalability, elasticity, and ease of maintenance. While in most cases cloud computing can improve security due to ease of management, the lack of knowledge and experience of the provider can jeopardize customer environments. This chapter discusses various cloud computing environments and methods to make them more secure for hosting companies and their customers.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128038437000636

Marketing Information Systems

Robert R. Harmon , in Encyclopedia of Information Systems, 2003

III. Customer Management Systems

Companies need a method for viewing all customer-and marketing-related information in an integrated way. Often, marketing organizations maintain multiple databases for each business and marketing activity with data that is not easily integrated for strategic or operational purposes. A new generation of software that is Internet based gathers information from customer service, Web sites, direct mail operations, telemarketing, field sales, customer service, distributors, retailers, and suppliers for the purpose of managing marketing, sales, and customer service activities. The major applications families are commonly referred to as sales force automation (SFA) and customer relationship management (CRM) systems. Some CRM systems are fully integrated with SFA applications and some are stand alone. The worldwide market for such systems is projected to grow five times faster than the overall software market, from $5 billion in 1999 to more than $22 billion in 2003.

III.A. Sales Force Automation

SFA is a customer management tool that is one of the fastest growing elements of the MklS. SFA applications are often integrated with the CRM system. SFA involves the application of information technology to the sales function or, more appropriately, to the activities leading to a sale. These activities include acquiring sales leads, managing the sales opportunity, closing the sale, and managing the customer relationship.

The historic role of personal selling has been to move the product—to generate transactions. As selling has become increasingly more professional, salespeople emphasize building relationships with customers that will generate loyalty-based repeat transactions over time. Relationship building often necessitates that the salesperson has consultative and advisory skills in addition to product knowledge and sales abilities. Team-based selling places emphasis on role specialization, collaboration, and coordination. Customers have become more sophisticated as well. Requirements for customized solutions, rapid response times, and the need for concurrent and postsale service have greatly increased the need for information technology in the sales process.

The goals of SFA are to increase the effectiveness of the sales organization, improve its efficiency, and create superior value for the customer. Sales effectiveness focuses on getting the sale by improving lead generation, qualifying prospects, coordinating sales efforts, and tracking commitments. Effectiveness is a function of improving the sales process. Sales efficiency is evaluated by measuring the return on sales efforts. SFA can improve sales efficiency by reducing sales cycle time, by managing workflow, and by tracking the current status of critical activities related to the sale. Proposal generation, opportunity management, fulfillment, and follow-up are facilitated by SFA. Superior customer value is achieved when the customer expectations are exceeded. It is a primary determinant of customer satisfaction. SFA enables better understanding of customer expectations and management of the customer account.

III.A.a. The Sales Process

The typical field sales process consists of a series of steps that are designed to lead to a sale. The typical role of the MklS is to support the sales process steps of lead generation, sales process management, and account management.

1.

Lead generation. Leads represent potential customers. The identification of a lead is the beginning of the sales cycle. After leads are identified, they must be qualified. This process involves gathering information about the lead and comparing the result against qualifying criteria. The lead generation process is becoming more automated with regard to obtaining more prequalifying information directly from the lead and augmenting it from commercial and other databases such as credit bureaus. The advent of Web-based technologies is driving this trend. Qualified leads are then distributed to the sales force.

2.

Sales process management. This process starts when the salesperson receives the lead information. The primary information system need is for a convenient method to track the process and store the data generated at each stage. There are a number of substeps to this stage of the process.

2.a.

Verification of the opportunity. The salesperson usually contacts the lead and attempts to verify the existence and nature of an opportunity including its size, timing, and appropriateness of the products and services of the selling company. Salespeople will also desire to verify the lead's ability to purchase, identify the names of key decision makers and influencers, and the level of budget authority. This information is entered into the sales database.

2.b.

The sales call. If the lead is amenable and the opportunity justifies it, a sales call is scheduled. Information may be sent to the prospect and a custom presentation may be created. The SFA system is used to provide a single point of interface for the salesperson to coordinate the activities leading up to the sales call. After the call, the SFA system is updated with customer requirements, new information, and commitments made by the salesperson.

2.c.

Opportunity management. If the salesperson is successful, the next step is typically the receipt of a request for proposal (RFP) from the prospective customer. The RFP will generally state the customer's requirements and the date for the final submission. Follow-up visits may be necessary to clear up or identify new requirements. The prospect may want to visit the seller's manufacturing site. The final product of this stage is the creation of a proposal and price quote to be presented to the prospect. This document should build a sound economic case for the purchase. All these interactions, requirements, commitments, and competitor information are tracked by the SFA system that provides the database, tools, and templates to generate the proposal.

2.d.

Closing the sale. The presentation of the proposal and the price quote is the start of the closing process. Even if the salesperson has done a good job of presenting the business case, further negotiations may be necessary to close the sale. If all objections are met and the proposal is accepted, the close is successful. If not, the sales team will need to debrief the lessons learned to determine why the proposal was not accepted. The outcomes are recorded in the SFA system.

3.

Account management. The automation of the sales process may result in a stand-alone system that is not integrated with other management systems. However, SFA is increasingly being integrated with the overall CRM system. This is especially true of the account management function. Since the primary goal of the CRM system is to manage the customer relationship in order to generate repeat sales, a good salesperson will want to keep track of the status of a new account and how well the customer is being served. This is especially true if the account is to become "referenceable" to other prospects. The account management function of the CRM system enables the salesperson to track order entry, order processing, shipment, and installation. The salesperson may need to ensure that postsales service is delivered or to monitor the results of installation and track the customer's satisfaction. The ability to track outcomes and interact with the customer in order to reassess needs and create new opportunities is a major benefit that flows from effective account management.

III.A.b. Sales Force Automation Tools

SFA tools consist of software applications that enable the salesperson to better target sales opportunities and manage the sales cycle. The tools are increasingly available bundled as integrated suites that are Internet enabled, accessible through a browser, and linked to the CRM system. The software applications may be categorized as:

1.

Document management tools. These tools support all stages of the sales process. They include word processors, graphics programs, spreadsheets, e-mail, expense reports, proposal generators, and "product configurators." A Web-accessible sales library or encyclopedia of previously developed product information, brochures, product demonstrations, presentations, financial information, price lists, white papers, and public relations materials is a key resource for sales force productivity.

2.

Personal management tools. These tools focus on increasing the efficiency and effectiveness of the sales teams efforts. They typically include calendar and scheduling programs, contact management systems, and call reporting capabilities.

3.

Process management tools. These tools are used to keep track of customer requirements and sales commitments. They include opportunity management systems, project management systems, account management systems, order-entry systems, telemarketing systems, and team-selling systems.

Increasingly, with the rise of Web-based hosting and the application service provider (ASP) industry, SFA applications and databases are being hosted by third-party specialists and accessed remotely on the Internet. With the ASP model, client companies are essentially outsourcing all or part of there information system function. Remote hosting raises issues of security and scalability. The advantages of an ASP approach are its browser-based simplicity, rapid implementation, and lower cost of deployment. Most ASP applications use a subscription-based pricing model. Some vendors are proposing that renting the application or paying by the transaction may become the pricing model of the future.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B0122272404001106

Enterprise application testing

Jeremy Faircloth , in Penetration Tester's Open Source Toolkit (Third Edition), 2011

8.2.3 Integrations

Enterprise applications are often integrated with other applications that exist within the corporate enterprise. For example, the corporation may be using an enterprise authentication solution to allow for single sign-on. In this example, the enterprise application would be integrated with the authentication provider so that the user could use the same credentials for authentication and have those credentials centrally managed through the authentication solution.

Another example of integration is at the data layer. It is very common within corporate environments to need to use the same data across multiple applications. However, the data structure for each application is usually different; therefore, the data must be transformed before it can be used in an application different from the source application. This data transformation can be done in a number of ways and in some cases may use an enterprise application designed specifically to handle data copies and transformations.

8.2.3.1 Real-time integrations

The last integration type that we'll discuss is real-time integration. In some cases, an enterprise application will need to pull data from a different application in order to complete some task. For example, when entering a customer's information into a CRM application, the application may need to query the shipping system to gather a list of shipments made to that customer's address. While that data may not be available directly in the CRM system, the CRM system may be able to use a real-time integration to pull the data from the shipping system. This is known as a "pull" real-time integration.

This type of integration also works in reverse where the enterprise application may send data using a real-time integration to another system. Using the last example of a CRM system communicating with a shipping system, a call-center agent may enter an order for a customer into the CRM system which causes a ship order to be sent to the shipping system. Naturally, this would be referred to as a "push" real-time integration.

Epic Fail

In some cases, integrations are the most vulnerable part of an enterprise application. Because these are intended to be used as a system-to-system method of transporting data, it is not uncommon for security around the interfaces to be lax. The "it's just an interface account" security approach has provided ample opportunities for penetration testers to use the reduced attention around these accounts to compromise enterprise applications. Frequently, an unnecessarily high level of privilege is granted to interface accounts due to a lack of understanding of what the interface really needs in order to execute properly and a lack of rigor around securing "service accounts" such as this.

Combining the two real-time integration types is also possible. For example, the CRM system may send the order to the shipping system, then wait for a response indicating that the product is available in inventory and a ship date has been scheduled. This is known as a "bi-directional" real-time integration.

All of these integrations can be direct system-to-system integrations, but most large enterprises have moved away from this approach. Is it far more common for yet another enterprise application to be put in place as an integration solution. The logic behind this is that multiple enterprise applications may need to have integrations to the same back-end systems. With a system-to-system integration, any time the back-end system changes, all of the connecting applications need to be modified as well. With an enterprise integration solution in place, it is often sufficient to simply make changes within the integration application and leave the application using the interface alone.

8.2.3.1.1 Web services

In some cases, real-time integration applications require the use of proprietary protocols or agent software. However, more and more interfaces are being built to use web services either as part of a service-oriented architecture or simply to increase ease-of-use of the interface. Web services are integrations based on a number of standards such as Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Web Services Description Language (WSDL) in such a way that they can be easily connected to and used by applications which need to push or pull data through the real-time interface.

Using these standards allows for enterprise application vendors to create their applications with built-in support for the standards rather than having to build in support for a wide variety of proprietary protocols. This reduces development time for the enterprise application, makes the application easier to support, and increases the application flexibility so that it isn't tied to one specific vendor for real-time interfaces. This allows for real-time interfaces to be developed that are reusable by multiple enterprise applications and (assuming the interface is built using appropriate standards) automatically be compatible with most enterprise applications out of the box.

Figure 8.2 shows a diagram of an example company with multiple enterprise applications and real-time interfaces.

FIGURE 8.2. Enterprise with Real-Time Interfaces.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B978159749627810008X

Testing enterprise applications

Jeremy Faircloth , in Penetration Tester's Open Source Toolkit (Fourth Edition), 2017

Real-time integrations

The last integration type that we'll discuss is real-time integration. In some cases, an enterprise application will need to pull data from a different application in order to complete some task. For example, when entering a customer's information into a CRM application, the application may need to query the shipping system to gather a list of shipments made to that customer's address. While that data may not be available directly in the CRM system, the CRM system may be able to use a real-time integration to pull the data from the shipping system. This is known as a "pull" real-time integration.

This type of integration also works in reverse where the enterprise application may send data using a real-time integration to another system. Using the last example of a CRM system communicating with a shipping system, a call center agent may enter an order for a customer into the CRM system which causes a ship order to be sent to the shipping system. Naturally, this would be referred to as a "push" real-time integration.

Epic Fail

In some cases, integrations are the most vulnerable part of an enterprise application. Because these are intended to be used as a system-to-system method of transporting data, it is not uncommon for security around the interfaces to be lax. The "it's just an interface account" security approach has provided ample opportunities for penetration testers to use the reduced attention around these accounts to compromise enterprise applications. Frequently, an unnecessarily high level of privilege is granted to interface accounts due to a lack of understanding of what the interface really needs in order to execute properly and a lack of rigor around securing "service accounts" such as this.

Combining the two real-time integration types is also possible. For example, the CRM system may send the order to the shipping system, then wait for a response indicating that the product is available in inventory and a ship date has been scheduled. This is known as a "bidirectional" real-time integration.

All of these integrations can be direct system-to-system integrations, but most large enterprises have moved away from this approach. It is far more common for yet another enterprise application to be put in place as an integration solution. The logic behind this is that multiple enterprise applications may need to have integrations to the same back-end systems. With a system-to-system integration, any time the back-end system changes, all of the connecting applications need to be modified as well. With an enterprise integration solution in place, it is often sufficient to simply make changes within the integration application and leave the application using the interface alone.

Web services

In some cases, real-time integration applications require the use of proprietary protocols or agent software. However, more and more interfaces are being built to use web services either as part of a service-oriented architecture or simply to increase ease-of-use of the interface. Web services are integrations based on a number of standards such as Extensible Markup Language (XML), Simple Object Access Protocol (SOAP), and Web Services Description Language (WSDL) in such a way that they can be easily connected to and used by applications which need to push or pull data through the real-time interface.

Using these standards allows for enterprise application vendors to create their applications with built-in support for the standards rather than having to build in support for a wide variety of proprietary protocols. This reduces development time for the enterprise application, makes the application easier to support, and increases the application flexibility so that it isn't tied to one specific vendor for real-time interfaces. This allows for real-time interfaces to be developed that are reusable by multiple enterprise applications and (assuming the interface is built using appropriate standards) automatically be compatible with most enterprise applications out of the box.

Fig. 7.2 shows a diagram of an example company with multiple enterprise applications and real-time interfaces.

Figure 7.2. Enterprise with real-time interfaces

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128021491000075

Patterns for the IT Lifecycles

Charles T. Betz , in Architecture and Patterns for IT Service Management, Resource Planning, and Governance: Making Shoes for the Cobbler's Children (Second Edition), 2011

Application – Service

Dialog: What's an Application Manager to Think?

Natalie is an Application Manager for a large midwestern manufacturer. Her responsibilities include both the development of new functionality for her system (the enterprise Customer Relationship Management system) as well as its ongoing operations. One day she is called into a meeting, at which a senior IT Service Management consultant is speaking.

Gary: The thing you folks need to do is get out of a technology-centered approach to interacting with the business. The business doesn't care about things like 'Applications'!

Natalie: Excuse me, why do you say that?

Gary: Well, it's clear. The business doesn't know what an Application is. You shouldn't even talk about it with them. What they need is a Service!

Natalie: I'm not providing a Service?

Gary: Not if you are calling yourself an Application Manager. All that Application Managers do is build technical stuff.

Natalie: Hmm. I just got out of a meeting with the senior VP for marketing. We were talking about my application's availability level. We even used the term 'SLA.' But this term 'Service' you're throwing around … we don't talk in quite the same way.

Gary: That's because you are too technical in your approach. See, you need to get out of the bits and bytes and talk in business terms!

Natalie: Like discussing the business objectives of the next major release with the SVP? How the Application (excuse me, Service) is going to help improve customer retention and sales force productivity?

Gary: Right. Say, I thought you said you were just an application manager.

Natalie: I did. Oh, never mind!

The relationship between Service and Application is the subject of much industry debate. ITIL® is strong on distinguishing the two, because its view of "application" is technical – it's simply the binary software executed for the customer. However, in many large IT organizations, an "Application" team is concerned with customer service issues and is effectively supporting a "Service" or system – not just technology, but people and process as well. Such customer-oriented application management teams would be very surprised to learn that they are "invisible to the Customer," as ITIL® v2 stated! iv

In many large IT organizations, an "Application" team is concerned with customer service issues and effectively is supporting a "Service."

There is great variability in the industry, and in other organizations the "Application" teams are indeed merely technical – in yet other organizations, there is no consistency; some Application teams are truly Service managers, and others are primarily software development shops.

From a Lean perspective, separating development teams from the ongoing transactional value delivery seems inadvisable.

However, from a Lean perspective, separating development teams from the ongoing transactional value delivery seems inadvisable. Lean philosophy and

Agile development would seem to indicate that application teams should be moved closer to the service "demand pull," rather than isolated to work on large batches of software to be thrown "over the wall" to a distinct service management capability.

Also, from a Lean perspective of "respect for people" comes a basic concern: if a group of people calls something "X," trying to change their language is difficult. It's especially problematic when the attempt is framed as "X is not good enough, you need Y" when the people believe (with some cause) that they have been "doing Y all along." If one truly is "going to gemba" and studying the work, respect for the people and the language they use is essential.

This author's view is clear in narrative and data model: applications are a subtype of service. Applications that are too "fine-grained" to be business-relevant should be consolidated into larger units, and large application suites supporting multiple business processes should similarly be decomposed.

Where the application is "Oracle HRMS," the service might be "Human Resources Application Management."

Service Abstract, Application Particular?

One proposed method of managing the distinction is linguistic. Where the application is "Oracle HRMS," the service might be "Human Resources Application Management." v

This approach has an advantage of conceptually decoupling the service to some degree from the application; however, the value-add of this linguistic distinction alone may be suspect, if all involved (wink, wink, nudge, nudge) know that it simply translates into the same set of services the Oracle HRMS team has provided all along.

A practical concern is that introduction of a layer of abstraction also poses maintenance issues: now two hard-to-manage logical Configuration Items must be maintained, with a mapping between them.

Another concern is if the "service" starts to take on strictly business connotations, e.g., "Human Resource Management." We are talking about IT Services, not business services. Describing the actual business architecture and understanding its services is a worthwhile endeavor, but not (in this author's view) IT management per se. (The closest we get is perhaps sending business analysts and architects over to the business to consult on such questions.)

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123850171000043

Software Tools

Alexander Borek , ... Philip Woodall , in Total Information Risk Management, 2014

Matching algorithms

In addition to the redundancy between columns of a data set, the records in the data set may contain duplicate entries. A common example to illustrate this is duplicate entries of customer records within organizational CRM systems. In this case, a customer may be recorded twice (or multiple times), and each of these records needs to be merged into a single customer record. This often happens because a customer may have been recorded at different addresses, women may be known under both maiden and married names, and children may have the same name (or initials) as parents, etc. It is, therefore, very difficult to determine whether two customers are distinct or not.

Many algorithms exist for detecting problems, such as whether any two (or more) records in a database refer to the same entity that the record represents. If identical records are detected, then there are additional algorithms that can merge the two records according to predefined preference rules. These algorithms are commonly found in master data management (MDM) systems, within which one of their aims is to remove duplicates in master data. One reason these algorithms are considered separately is that not all cases can be resolved automatically. The detection algorithms can be used to flag candidate records for merging and pass these either to the automated merging algorithm or to a human operator who can manually review the decision and perform the merger if necessary.

The challenge with the detection algorithms is to correctly configure them so that they capture all the cases you want them to, and that they do not miss cases where records should be merged. There are many names for these algorithms, including record linkage, merge/purge problem, object identity problem, identity resolution, and de-duplication algorithms.

The detection algorithms can be placed into two categories: deterministic and probabilistic. Deterministic algorithms work by comparing the values for certain attributes between the two records, and if they all match, then the records are flagged to be merged. The example records about engineering parts in Figure 12.3 show two records that can be deterministically linked. These two records are both about the same part, but the descriptions are slightly different and the color is missing for one of the records. However, the part ID and weight attributes contain the same values and therefore indicate that these refer to the same part. From this example, you can see how the challenge is to configure the algorithm correctly by specifying the attributes that indicate when the records match. If the description attribute was also required to have matching values, then the algorithm would indicate that the records do not match. For deterministic matching, you must be sure that the set of attributes that must match are correct. Otherwise, there are two possible erroneous outcomes: two records will be thought to be the same when they are not, or two records do refer to the same entity but they are not considered to match. Deterministic record linkage is, therefore, ideal when reliable unique identifiers can be found for an entity.

FIGURE 12.3. Deterministic record linkage.

Probabilistic algorithms provide a further level of configuration, and allow weights to be set for every attribute. Usually, there are two probabilities that need to be specified for an attribute. The first, m, is the probability that a common attribute agrees on a matching pair of records, and the second, u, is the probability that a common attribute agrees on an unmatched pair of records (nonmatching records agree simply by chance). For instance, gender usually has two possible values (female and male) that are uniformly distributed, and therefore there is a 50% chance that two records will have the same value for this attribute when they are not a match. These probabilities are used in the standard record linkage algorithms to give a final weight for each attribute, and then are summed to give an overall value that indicates whether the algorithm considers the two records to be a match or not.

In many cases, for a particular attribute, two records may have very similar values that are not exactly the same. Observe the "Description" field values in Figure 12.3 (O-ring and ring) that differ only by two characters. This type of difference is very common in all areas; names of people, addresses, and customer reference numbers may all contain small typographic errors that mean they do not match exactly. Approximate string matching (also known in some instances as fuzzy matching) can be used to address this problem, which effectively tolerates the various differences that can arise between values. Table 12.3 shows the typical examples that approximate string matching algorithms can handle. Using approximate string matching algorithms with record linkage algorithms is therefore very common and can lead to a more reliable record matching solution. Standard MDM solutions already contain these algorithms and they often provide intuitive and convenient ways of configuring the parameters to suit various cases.

Table 12.3. String Differences

Operation Example
Insertion abc → abcd
Deletion abc → ab
Substitution abc → abd
Transposition abc → cba

To assist with approximate string matching, lexical analysis can first be applied to the data to help standardize the values. The difference is that with lexical analysis, the values are actually changed before the matching algorithm runs, whereas relying on approximate string matching means that the values do not actually change. The algorithm can tolerate the differences during its execution.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780124055476000122