NextGen Consulting

IT Consulting CRM BSS OSS

Data Objects Map


27/01/2011 Posted by | Amdocs, Backend, BSS, CRM, CRM, Development, Front End, Technology | Leave a comment

Contact Resolution Management


Numerous managers have gotten “First Call Resolution Forever” and/or “Done in One” tattooed on their necks.

The majority of conversations about FCR center around two things:

  1. The huge potential impact of First Call Resolution (on operational costs, customer satisfaction and agent satisfaction / retention);
  2. How to measure this mega-metric accurately

See the original full discussion in Greg Levin’s Rev Up Your FCR Rate.

In his article, Greg discusses the following list of tactics to increase First Call Resolution efficiently:

  • Excellent agent training and tools
  • World-class workforce management processes
  • No conflicting performance objectives
  • Incentives around FCR goal achievement
  • Agents empowered to improve FCR-related processes

Amdocs Customer Interaction Manager (CIM) provides an excellent platform for achieving these goals.

 

Contact Management 

Contact management (or CIM – Customer Interaction Manager in Amdocs terminology) refers to a unified desktop application that enables customer facing agent (or CSRs -Customer Service Representatives) to effectively manage media exchanges with their customers.

The user interface is context-driven, and provides agents with immediate access to all relevant information to assist them end up the interaction in timely manner while having satisfied customers.

Relevant information refers to customer information (personal and / or organizational), interaction history (previous contacts) and service history (previous case handling), products and subscribed services, usage of services, service level agreement(s), likes, habits, social behavior, billing information etc.

Customer Interaction Manager combines with Multimedia Integrator to provide a multimedia interface for variety of communication channels such as interactive voice response (IVR), computer telephony interface (CTI), email, and smartphones applications (not provided with core product – requires customization).  The Multimedia Integrator displays an application toolbar that agents can use to efficiently manage inbound and outbound voice, and other media exchanges.

 

Contact Management Concepts

The contact management, focused on the interaction paradigm, is based on the following key Concepts:

Interaction    
Interaction is defined as an exchange of information between a single customer and the agent (or CSR – Customer Service Representative), using one or more channels. The interaction provides a full view of the customer data.

 

Unified Desktop:                
The desktop UI seamlessly provides one front end used by customer facing agents (front of house) which is shared among several applications, covering variety of domains such as CRM, Billing, Ordering, Product Catalogue, Installed Repository Management, and Social Behavior Analysis.

 

Increased Efficiency:         
The shared front end desktop provides an immediate access to any required information during customer interaction. Immediate information access is achieved by minimized key strokes, reduced eye and mouse movement and focus on actionable data. These facilities allow agents to focus on customer service and quickly address raided issues.

 

Toolboxes:                        
Common persistent desktop areas which keep important information always available and enable easier navigation.

 

Contact Management Components

Find Caller

The Find Caller module is used to help the agent quickly identify the source of an incoming call and effectively link it with the relevant contact, service and product.

Depending on the context of the exchange, the agent can seamlessly employ, within the shared desktop, variety of complementary backend services to assist them quickly complete the interaction.

The Find Caller performs different database queries according to the context of the interaction. If the Multimedia Integrator is enabled, it automatically launches the Find Caller feature for inbound calls. If this application is not enabled, the agent can enter contact details and activate the search manually.

A manual search can also be used for outbound calls, for example when used in conjunction with a predictive dialing application.

Find Caller functions in Contact Manager in the same way as in other CRM Smart Client applications, and posts the Search: Contact and Account window as the default search option.

When a valid Billing Manager Client license is installed, Find Caller provides extended search functions for billing, subscription and mobile phone information.

  • Each CRM Smart Client application that deploys Find Caller uses its own server side search (i.e. Worker Bean) to launch the function. For Amdocs Customer Interaction Manager, the generic Find Caller worker bean FindCallerWB is extended by the application-specific worker bean FindCallerCIMWB.
  • Multiple applications can launch their special version of the Find Caller form. For example, Billing Manager, FindCallerWB is extended (by the Billing Manager worker bean FindCallerBMWB) to load its Find Caller version.

 

The following UI forms are commonly used by the contact manager module:

  • FindCallerToolbar.             Displays the current contact and account information on the application bar.
  • FindCallerCimSearch.        Contains the UI controls used for extended searches.

 

Find Caller Search Criteria

As discussed above, the Find Caller module provides two core search types:

  • Customer Interaction Manager Search
  • Billing Search

Each search type has two presentations, one for basic searches and one for extended searches.

 

The default Customer Interaction Manager search form contains the following search fields:

  • Phone
  • Account ID
  • First Name
  • Last Name
  • Email
  • Account Name
  • Customer ID
  • Customer Alias
  • Alternate Contact Method
  • Mobile
  • Serial Number
  • Billing Arrangement ID
  • Financial Arrangement ID

 

Automatic Find Caller

When the Multimedia Integrator is enabled, Find Caller is conducted automatically for incoming calls, and populates mobile phone number and subscription fields accordingly, when the details exist in the database.

 

 Anonymous Caller

Anonymous Caller is a caller who cannot be identified.

In the case where the initial Find Caller search does not find contact details in the database, Customer Interaction Manager allows the agent to assign the caller as Anonymous Caller. Details are then set to anonymous data and the agent enters new information for this caller.

 

Reason Codes

Reason codes refer to a three level hierarchical attributes structure which systematically describe the reason for the call and resulted action. These attributes can be later used for BI analysis.

Reason codes drive downstream processes and can launch relevant activities if necessary

Few reason codes examples are:

 

Visually, above reason codes are implemented as drop down lists, as shown in the following pictures:

   

 

Reason Codes Selection Flow

The Reason1, Reason2, and Result drop-down menus are formed by a hierarchical, user defined pop-up list (UDPL). When an CSR selects a Reason 1 topic, the application updates the list in the Reason 2 drop-down menu. The CSR can then select a Reason 2 topic that is specific to requirements.

 

In addition to the predefined lists of reason codes provided with the application, customized combinations of reason codes can be customized to implement any specific business logic requirements.

 

Topics

A topic represents set of reason codes, their result action and a possible linked object. An interaction may have one or multiple issues raised from one customer enquiry. Each issue represented by a topic. A Topic comprised of two reason codes and a result action code. Topic Tracks the issue(s) for the interaction.

 

Context Manager

An important part of the contact management is the Context Manager. The context manager allows handling several open interactions concurrently by providing the agent the ability for quick context switching between callers while they are on the line.

Interaction context gathers all information presented to the agent during the course of an interaction. Context switching refers to the ability to serve several calls simultaneously while keeping their complete interaction information immediately available by merely selecting the caller name.

The instant context switching (less than 1 sec) is technically achieved by caching all information in memory once it is retrieved from its persistent storage.

In the following pictures, the following two contexts are displayed:

 

Visually, above contexts are implemented in the UI as follows:

                                                                        Context 1

 

                                                                        Context 2

 

Action

Action specifies a result activity which is part of a topic. An action can be a single, short-duration activity, presenting a form, creation of a workflow object for a long duration handling process, or a complex business process which may drive one or more workflow objects.

 

Workflow Objects  

 Known also as workflow tasks, these objects represent continues task which may involve more than one owner during their life time. A workflow object represents any type of long duration task. Example for long duration tasks could be service assurance issues (cases), scheduled activities (Action Item), Change process (Change Request), Opportunity, Sales Quotation (Quote), Order, etc.  

A workflow object has a lifecycle, starting from its creation until it is closed. At any point of time a workflow object is owned by single owner. Ownership can be transferred between owners via intermediate parking lots named Queues.

Ownership is transferred only by mutual handshake process known as ‘Dispatch – Accept’.

A workflow object has several attributes which are continuously updated either explicitly or implicitly to reflect its handling position. The most notably attributes are ‘Condition’ and ‘Status’.

 

Only owners are allowed to change the workflow object’s status. Status changes must follow specific rules known as ‘Status Transition Map’. This map comprised of pre-defined set of rules which specify, for each status, one or more allowed target status values and the allowed role to perform the change.

 

Contact Management Implementation

Contact Management (or Customer Interaction Manager) UI is implemented using Amdocs Smart Client, a rich client architecture which provides flexibility of a Web application. Smart Client applications are deployed over the web and require minimal client-side installation. The front end UI is automatically updated without user intervention while providing the look and feel of a native desktop application.

Contact Manager UI provides the agent with the following operational areas:

  • Find Caller form
  • Interaction Home
  • Customer Overview toolbar
  • Multimedia Integrator toolbar
  • Interaction toolbox

 

 

Contact Management Events

 The Interaction Home page has Quick Action buttons for the several predefined events, such as Case, Action item, Literature request, Sales Opportunity, Sales Quote, Order, Pending credit and Promotion

The standard CIM implementation provides a number of predefined events.

 

  • The agent can trigger these events either by selecting a combination of reason codes or by clicking a Quick Action button on the Interaction Homepage.
  • Each Quick Action button (or reason code combination) uses a Launch Action function to launch the following sequence of events:
    • It may launch an application form (I.e.  CRM or Ordering applications)
    • It may launch an automation process (backend driven or UI driven)
    • It retrieves attributes from the Context Manager and passes them either to the launched form or process.

 This technique can be used to launch any window from any Amdocs CRM application in the interaction flow.

 

Implementing an Event with Reason Codes

Customization can add more functionality to the application or can tailor the application to meet any specific needs. Some commonly customized items include the following:

  • Launch actions
  • Launch wizard scripts
  • Interaction Home form
  • Toolbars
  • Toolboxes

 

 

 

10/01/2011 Posted by | Amdocs, BSS, CRM, CRM, Customer Interaction Management, Smart Client, Technology | 1 Comment

Interaction Management Process


Process Design Questionnaire

  • Who do your call center agents interact with?
  • Customers only?  Dealers?  Partners?
  • What types of interactions are received / sent out?
  • What is the structure of the call center?
  • What is the number of Agents?
  • Will these users be divided into functional groups?
  • Will users have access to some forms/commands/data and not others?
  • Number of Call centers?
  • Where are they located?
  • How many agents are there at each location?
  • What is the number of interactions handled per agent per day?
  • How do you measure your call center agents?

Generic Interaction Management Process – part 1

Generic Interaction Management Process – part 2

 

Generic Interaction Management Process – part 3

 

Generic Interaction Management Process – part 4

 

 

Generic Interaction Management Process – part 5

 

 

 

Sample Implementation Decisions


04/01/2011 Posted by | Amdocs, BSS, CRM, CRM, Customer Interaction Management | Leave a comment

Migrating Amdocs CRM Classic to Smart Client (part 1)


Business justification for migration from classic to smart client technology is a difficult subject.  In some respects migration can be seen as having purely IT benefits, such as reduced deployment costs, reduced maintenance costs etc. 

The main business drivers for migration are often based on leveraging new functionality that is available in the smart client, not available the classic client.  This means that a purely technical migration will likely result in limited or no identifiable business benefits, making the business case very difficult to prove. 

In many cases both technical and business drivers arise during the migration assessment.

It is important to understand that although both technical and business drivers for migration are viewed separately, there is an overlap between the two areas, as improved functionality is enabled through the use of the new architecture.

 

Read the full story Migrating Amdocs CRM Classic to Smart Client (Part 1)

 

09/10/2010 Posted by | Amdocs, BSS, CRM, CRM, Smart Client, Technology | Leave a comment

Using Contained Core Business Objects


Q. When working with establish relation, I had a problem with a Bo having many parent, like:

1. We have an exist CaseBo object:  caseBo
2. By using XVO, we create 2 new row to insert: emailLogBo and actEntryBo
3. In which: actEntryBo is child of both caseBo and emailLogBo, emailLogBo also is child of caseBo.

=> how can I insert emailLogBo and actEntryBo to database ?

Note that: Both emailLogBo and caseBo are parent of actEntryBo, so we can’t use actEntryBo.setParentBo(..) to set up relation. So, please suggest how to solve this problem.

 

A.  Note that CaseBo object contains all the logic to do it automatically for you.
All you need to do is to add your new emailLog record to the CONTAINED emailLogBo.
When doing so, an actEntry will automatically be added and related with all relevant BO parties (CaseBo, UserBo, EmailLogBo).

About Contained Business Objects

Many BOs Contain other Business Objects. These contained CBOs are exposed as properties of the containing BO. For example, when a Case BO is created, contained BOs are automatically created for the logs related to the cases, the site and contact that reported the cases, and the installed part identified in the case

These contained CBOs are automatically related to the Case BO, usually as child BOs of the parent BO. They are accessed through CaseBO properties.

Field values for contained CBOs are accessed through properties of the containing BO
The following code shows how to get the first name of the contact who logged a case: String firstName=boCase.getContact().toString(“first_name”); 

     
Note:

  1.  Most contained CBOs are Generic BOs.
       
  2. To reduce network traffic and improve response times, many contained BOs set bo.DataFields and bo.QueryMode to minimize the amount of data retrieved. Make sure to modify the DataFields property of the contained Bo to include necessary fields before performing the query.

 

  
Example: 

String fields= boCase.getContact().getDataFields() + ",e_mail";
boCase.getContact().setDataFields( fields );
boCase.query();

  

Example of adding email log to a CaseBo: 

  
// Add a new row to the contained EmailLog BO.
boCase.getEmailLog().addNew(); 

// Set the note description for the new row.
boCase.getEmailLog().setValue("description",
  "Customer mailed again to ask about the case status"); 

// Commit changes to the database.
boCase.update();
 

01/10/2010 Posted by | Amdocs, Backend, BSS, CRM, CRM, Development, Smart Client, Technology | Leave a comment

Upgrading AmdocsCRM Smart Client form (Part Two)


Preface

The original out of the box AmdocsCRM application quite often contains forms which deliver none-optimized user experience; these forms display too much information and lack context sensitive functionality. For certain business scenarios part of the displayed information is either irrelevant or overloaded.

These forms do not take full advantage of the rich client capability provided by the Smart Client underlying Java SWING technology.

In this two part posts I try to demonstrate how the SWING technology can vastly enhance user experience and improve usability by merely rearranging form layout and adding simple logic to it.

In part one I have demonstrated the first steps in upgrading an original, out of the box, Smart Client create case form.

I created an inherited version of the original form, created a form version selector to redirect the application to the newly created inherited form, verified the inherited form, then started to rebuild the new version by first moving all original controls to a parking lot (the ‘Unused Controls’ area), and rearranged the form layout.

Note that all the logic provided with the original form (dataset, code) is still active in the new form, but since all original controls are invisible (moved to the unused controls), I can invoke the new form but can not interact with it yet due to the hidden controls.

A new grid was defined for the root panel: One column and two rows. The single column has a predefined width size (initial form width size of 800 pixels) and will stretch itself (‘growable’) to allow it expand to the full screen width.

Assuming the minimal form height is 600 pixels, the first row was defined to an initial constant height of 555 pixels and growable to provide space for the main form area, while the lower row was defined as a fixed (none growable) 33 pixels height to provide exact space to contain the form’s buttons.

Each of the two rows was populated with a card panel UI control on which second level panels may be added. This gives the flexibility to add several fully overlapped panels under the card panel. Each of these panels can later expose different sets of controls according to the business process context. This paradigm allows for enhanced user experience by exposing only context relevant information at a time. This time we placed only a single panel under each card: crdMain / pnlMain for the main area and crdButtons / pnlButtonsMain for the lower row.

For the lower row buttons area, the new layout is simple: I redefined the panel’s (pnlButtonsMain) grid to contain a single row having a constant height of 22 pixels, and a horizontal strip of ten none-growable columns, each was set to have an initial constant width of 60 pixels (some width size were extended laters).  One column (marked with red arrow) was set to growable, to allow the buttons strip to expand to full width of any form / screen size.

 

Next we need to place all relevant controls in their new locations. All relevant original buttons (those previously moved to ‘Unused Controls’) were moved back from the ‘unused controls’ area to their new locations on on pnlButtonsMain:

 

The upper, main area (pnlMain) was subdivided using the following 5 X 5 grid:

The numbers in red denote the column / row fixed size and an optional (G) whether they are growable.

Note the spacer rows (5 fixed pixels width / height) that initially leave nine real estate rectangle areas (areas A – I), each populated with its own card panel and one or more flipping panels attached to it (eventually, these nine areas are reduced to five dispayable areas).

The three main columns are growable and have similar stretching relative weight. The similar stretch weight guarantees they will evenly stretch within the size of their containing form.

Display Topics

Each area within these columns will be used to display one topic (group of related controls) per panel.

A card panel can display a single panel at a time or flip panels according to some business logic. Each panel practically displays a group of related controls (called topics).

The division to distinct areas provides a convenient, readable view, allowing the human eye to easily capture and grasp each topic’s content.

Reducing the Number of Display Areas

In order to reduce the number of topics, some adjacent areas were defined to share a single card panel (a card panel can occupy one or more neighboring areas). Thus areas A and B share the card panel crdMainA, areas D and E share crdMainB and areas G, H & I share crdMainC.

Placing the Controls

All card panels, except for cardMainC, currently relate with only one panel which is dispaled by default (in other words, they do not flip panels).

Let’s have a further look at cardMainB / pnlMainB1

 

The panel pnlMainB1 layout use a 1 X 3 grid; a single fixed 125 pixels height row, and two subareas, having 220 and 240 pixels width, separated by a 5 pixels devider. Each display area use its own panel: PnlMainB1Inner (Case Type) and pnlCaseIndicators (Case Indicators).

Each of these panels has its own grid layout i.e.: Case Type. Once the grid layout was defined, I was then able to move back the original UI elements from the unused controls to their new location.

As mentioned, the original logic still works with these controls; there is no need to write any new code for them.

Now let’s view the lower card panel crdMainC:

Under this card panel we find pnlMainC1 and pnlMainC2. Unlike the previous example, where the two subpanels were placed on a parent panel grid, each at its own space (therefore displayed together), here we find two panels directly located under a card panel. This layout allows only one of them to be displayed at a time (since both occupy whole parent card panel space).

Each of these panels further carries its own layout hierarchy to support exact layout.

We need now to add logic that will allow the application to respond to user selection and expose the panels, each at a time. In order to provide this interactive functionality, a hyperlink control was added at the upper right corner of each panel.

On pnlMainC1, a hyperlink labeled ‘Details’, on pnlMainC2, a hyperlink labeled ‘Notes’.

Clicking on the Details hyperlink should trigger the application to display pnlMainC2 and Clicking on the Notes hyperlink should trigger the application to display pnlMainC1.

First we had to associate an action – an action object that is invoked when a hyperlink is clicked – to each of these hyperlinks. We associated both hyperlinks with the selectTabPanels action

Here is the selectTabPanels action definition:

And here is the code associated with the action’s start event. This code is invoked when actions associated controls (the Details and Notes hyperlinks) are clicked:

Note that the actual control (hyperlink) that was clicked and triggered the event is identified out of the event data. The name of the panel to be displayed is retrieved from the user data associated with the clicked hyperlink. The User Data programmatically added to the control when the form is initialized:

The actual panel replacement performed by the updateControls() method:

There are numerous additional features that were added to the upgraded page but not described in this post due to space limits.

To watch the new form in action, click the following link Create Case. 

31/05/2010 Posted by | Amdocs, BSS, CRM, CRM, Smart Client, Technology | 7 Comments

AmdocsCRM Releases: From Clarify 11.5 to AmdocsCRM 8.x


Q: Right now I’m working on Clarify thick Client 11.5.

 I need information like what are new versions available (details on new versions of thick, thin and smart clients) and nomenclature followed to represent a specific version of Client.

How are they differentiated from architecture point of view? Where can I get more information of current updates, releases, versions of Amdocs Client?

If we upgrade from thick to thin or smart client what parameters must be considered like DB used, version of DB and all.

 

Amdocs CRM Releases 

Since Clarify version 11.5, the following versions were introduced: ClarifyCRM 12.1, ClarifyCRM 12.5 and ClarifyCRM 13.1.

 As of ClarifyCRM 13.1, Amdocs changed its name and number to AmdocsCRM 6.0. (That means – both Clarify version 13.1 and AmdocsCRM 6.0 refer to the same release).

 AmdocsCRM 6.0 (Clarify 13.1) was the last version to introduce new functionality for Thin (Web) client).

 AmdocsCRM 7.1 was the first release that offered Smart Client (Java based client).

 However, the first fully matured Smart Client was released on release 7.5 (Italy).

 

The following versions are currently available:

  • AmdocsCRM 7.5.2  Supported clients: Thin (Web) and Smart Client (JNLP)
  • AmdocsCRM 8.0 Supported clients: Thin (Web) and Smart Client (JNLP)

 

As of release 7.5.2, a multi language support was added on the database (Oracle) level. This is not supported by classic client.

Note that since version 11.5 the Classic client releases have not added new functionality provided in both Thin and Smart Clients.

For example, the Customer Interaction Manager (CIM) module (call center agent’s main screens) is not provided out of the box classic client.

Architecturally, Classic client is a fat client which connects either directly to the database (2 tier) or use Tuxedo as an intermediate layer (3 Tier). In both cases, all logic is performed mostly on the client using a Visual Basic 5.0 dialect named ‘ClearBasic’.

Thin client and Smart Client use Java J2EE architecture. This architecture separates the application logic between a server side code (implemented as Java Beans) and client side, implemented as JSP / JavaScript for thin client, and as Java / SWING code for smart client.

 

Supported Platforms:

Server Platform Support

Operating System

  • Solaris 10 patch level: Generic_120011-14 (Sep 07)
  • Win 2003 SP2 current patch
  • HPUX 11iV2 RISC & HPUX 11iV2 Itanium
  • AIX 5.3 TL06 SP1 Patch level: 5300-07-02-0000 (Feb 08)

 

Database

  • Oracle 10gR2 10.2.0.3
  • MSSQL Server 2005 SP2 Standard J2EE Server.

 

JVM/SDK Solaris:

  • WebLogic 9.2 MP1 with Sun Java 2 SDK 5.0 update 12 with the Java HotSpot Client and Server VMs (32-bit)
  • WebLogic 9.2 MP1 with Sun  Java 2 SDK 1.5
  • HP:        WebLogic 9.2 MP1 with HPUX SDK 5.0.08 (32-bit) with Java HotSpot Server VM.
  • IBM:       WebLogic 9.2 MP3 with IBM SDK 5.0 SR5a 32-bit JavaTM.
  • IBM:       WebSphere 6.1.0.9 with IBM 32-bit SDK for Solaris, Java 2 Technology Edition, Version 1.5.
  • IBM:       WebSphere 6.1.0.9 with IBM 32-bit SDK, Java 2 Technology Edition, v1.5.
  • IBM:       WebSphere 6.1.0.9 with HP SDK for J2SE

 

Client Platform Support

  • Classic Client:        Windows Pro XP SP2 & Vista Business Edition
  • Thin Client:            Windows Pro XP SP2 & Vista Business Edition
  • Smart Client:          Windows Pro XP SP2 & Vista Business Edition

 

Browser

  • Classic:                                  N/A
  • Thin:                                    Internet Explorer 7
  • Smart:                                  N/A
  • JRE Classic, Thin, Smart:          1.5_12

  

Upgrading from Classic 11.5 to Smart 8.0

For this upgrade you need to consider the following:

  1. Upgrading your current database to Oracle 10gR2 10.2.0.3 (AmdocsCRM 7.5) or Oracle 11g (AmdocsCRM 8.0).
    This might require possible changes in your data model (for example, moving from ClearCallCenter or ClearSupport modules to the newer Customer Integration Manager data model).
        
  2. Migrating your application logic from Classic Client to Smart Client.
    This requires updating your customized UI from VB to Smart Client SWING, and updating logic from ClearBasic to Java server side and client side.

 

Q: This information is very informative. I do have one somewhat related question on this (note – I’m not very technical on Amdocs CRM):

Since the older version of Clarify 11.x (or AmdocsCRM 6.x) and the latest 8.x version, how much has the underlying data model changed?

My understanding is that Amdocs has not been making significant data model changes (new or modified tables/columns)..etc. Is that true?

Secondly, what exactly (in summary) is this ‘ClearSupport modules’ to ‘Customer Integration Manager’ data model change that you mentioned?
Does Amdocs provide a good packaged upgrade path/solution to move to newer versions?

Thank you in advance.

 

More About AmdocsCRM Releases

AmdocsCRM 6.0 is the same release as ClarifyCRM 13.1 (not Clarify 11.x). Note that between releases 11.x and 13.1 there were several releases, the most significant one was ClarifyCRM 12.5.

 

Upgrade Path from Clarify 11.5 to AmdocsCRM 8.x

Q:  Does Amdocs provide a good packaged upgrade path/solution to move to newer versions?

In order to upgrade from Clarify 11.5 to AmdocsCRM 7.x or 8.x you need to:

  1. Upgrade your existing database software from Oracle 8.X to Oracle 10gR2 10.2.0.3 (AmdocsCRM 7.x) or to Oracle 11 (AmdocsCRM 8.x).
         
  2. Migrate (upgrade) your database scheme (data model) from Clarify 11.5 to AmdocsCRM 7.5. via Clarify 12.5, AmdocsCRM 13.1 and AmdocsCRM 7.1 (full details are provided with each AmdocsCRM release notes which specify the exact migration path).
        
  3. Migrate your customized UI and logic (code) from ClearBasic to Java (server side and client side).

 

Technology Changes

Q: How much has the underlying data model changed from Clarify 11.x to AmdocsCRM 8?

The underlying data model has been significantly enhanced, both for the underlying technology and the provided functionality.

 

Technology Enhancements

New technical features were introduced to enhance performance, sizing etc.

Few Examples:

  • Support larger number of unique records per database table. The old objid primary key mechanism now supports the full 32 bits.
        
  • Additional key named GUID was added to support unique record string id.
         
  • Search field object mechanism was added to enhance performance (the search field allows user defined pop-ups to use be used by reference, in similar fashion to application pop-ups, rather than by value.
        
  • All popup menus are referenced by ref_id rather than by their nominated names.
        
  • Multi-lingual support was added at the database level.
        
  • Ability to define a schema object (table or view) using SQL query.
         
  • The old data dictionary compiling application (ddcomp) was completely rewritten for a much more reliable java code and is now called Schema Manager.
         
  • The licensing scheme was greatly enhanced. You need a proper Amdocs license in order for your J2EE server side code to properly run.
        
  • Most importantly, the server side code exclusively use CBO (Crm Business Objects) to access the data in the database. These CBOs were upgraded to use JPOMS, replacing the old POMS.
        
  • Clarify Process Manager (CPM) was replaced with Amdocs Process Manager (APM). APM provides much more sophisticated functionality, and can work with any other Amdocs products (it is largely used by Ordering).
        
  • Smart Client technology now allows the front end UI to interact simultaneously with several backend applications.
       
    For example: CRM and Ordering.
    In other words: Both CRM and Ordering share e unified desktop front-end UI.

Note that until lately (version 7.5), most these changes impacted the new J2EE technology, but still allowed legacy Classic client to co-operate with the same database. However, Classic legacy code was not updated to take advantage of the newer enhancements.

 

Functional Enhancements

1.     Billing Manager

Since Amdocs acquired Clarify, they decided that the Clarify UI (initially Classic, then Thin/Web, now Smart Client) to be used as a front end UI for all Amdocs Products.

Initially, main efforts were spent for adding UI screens and logic to provide seamless integration with billing functionality. (Billing Manager module, support Amdocs Billing or any other 3rd Party billing).

 

2.     Customer Interaction Manager (CIM)

Although legacy Clarify provided a Call Center module (Clear Call Center), it appeared that the data mode used for CCC (Clear Call Center) was inefficient nor flexible (i.e. – it created a Case record for each interaction).

A completely new data model and supporting UI screens and logic were introduced. The CIM model creates a light Interaction record for each interaction with a customer.

An interaction is NOT a workflow object, but merely a data record that stores the following call related data:  Title, Notes, Direction (outbound, inbound), Channel (800), Media (call, email, or chat). 

Each Interaction is related to one or more TOPICS. A topic is an issue raised by the caller. Each topic is categorized by at least two call reasons (identifiers), a possible, not mandatory, linked related Workflow object (such as Case), and a result code.

 

In practice, each topic may potentially initiate a call center process, such as an Order.

One of the most important CIM features is the ability of the call center agent to handle several interactions simultaneously. Each interaction with a caller is identified by caller’s name. The agent can toggle among several on-line interactions (each has its own different caller) while holding the caller on the line. When switching from one interaction to another, all interaction related data and UI is automatically switched as well and exposed to the agent.

An interaction can be used with an Anonymous Caller as well.

 

3.     Multi Media Integration

AmdocsCRM now supports a sophisticated integration module with external Interactive Voice Recognition (IVR) systems. It allows call center agents to accept calls, put calls on hold, transfer calls among them etc.

All IVR control is performed from the agent’s desktop. It also supports alternative media such as conducting a live chat etc. 

The multimedia integration also allows passing IVR parameters automatically to the interaction screen.

 

4.     Ordering Integration

As of release 7.5, ordering module UI and front end logic is integrated with CRM UI. It is possible to initiate an order process directly from CRM interaction screen with a single button click.

 

5.     Enhanced Support Module

There were many enhancements to the support module here is one of them:

 

SLA (Service Level Agreement) Manager

Tracking service level agreements (more on this in a separate post).

 

Role Based Authorization (RBA)

Control UI and backend permitted user activities according to their Global, Group or User Roles.(See more on this in Role Based Authorization).

 

Case Types
Case types are not only 3 keyword identifiers stored with a case record, but a whole definition which allows different screens to popup according to the type of the case.

 

Summary

Yes – in order to support all above changes (and many, many more) Amdocs have added significant enhancements to the underlying data model.

 

ClearSupport Vs Customer Interaction Manager

The ‘ClearSupport’ module is a separate module from ‘Customer Integration Manager ‘(CIM). They use completely different (although compatible) data models.

You should regard the Customer Interaction Manager module as an enhancement to the Support module.

From business process perspective, any customer call starts with the ‘Customer Interaction Manager’ to handle the call (interaction).

An interaction may, or may not, propagate to a process handled by the Support module (i.e. a service call).

For example – if a customer calls to ask a question and immediately get an answer, only Interaction record needs to be created, no Case is created (this is sometimes called ‘Done in One’).

On the other hand, if a customer calls and complaints about a service, or a billing issue, where the issue can not be immediately resolved, a process needs to be initiated to handle the issue. A Case record is then created, and the Support module handles this Case according to its type until the issue is resolved and the Case is closed.

 

04/05/2010 Posted by | Amdocs, BSS, CRM, CRM, General | 4 Comments

NextGen Consulting – IT consulting services


Welcome to NextGen Consulting.

We provide IT consulting services to organizations who use Clarify or Amdocs CRM products.

Having over 10 years with full life cycle of Clarify / Amdocs CRM projects, we offer flexible variety of services aimed both at the telecom and the enterprize organizations.

Our people have hands-on implementation expertise with Clarify Classic Client, AmdocsCRM thin client, and Amdocs CRM Smart Client.

We offer your organization this expertise to help you migrate from either Classic or thin to Smart Client, or simply provide high level design, low-level design and customization to fit your organization needs.

For further information view profile at  http://il.linkedin.com/in/yuvalr
or contact Yuval Rashelbach at yuval.rashelbach@nextgencon.com

 
 
 

24/02/2010 Posted by | BSS, CRM, General, OSS | 1 Comment