Archive for the ‘Opinions’ Category

Xactly Incent 4.0 – Effective Dating and Other New Features

May 31, 2008

Xactly will be releasing the new version of its On-Demand Sales Compensation Management application in the next week or two.
The main changes in Incent 4.0 will include an improved user interface and reports, “effective dating”, improved organizational management and advanced searches.
User Interface and Reports:
The interface looks good and most of the changes were made around the new functionalities for effective dating. The reports look prettier and also have new security/privacy features. More reports are available and they work “out-of-the-box”. As far as I know these reports are still not very customizable, so it will be important to make sure they satisfy the reporting needs.
Effective dating:
This is a feature I described earlier when discussing versioning. Effective dating allows to give a certain value to an object between certain dates, and a different value between other dates. This can be used to track changes to teams and reporting releationships, job or role changes, promotions, name changes, targets, etc.
For example, if a person’s salary goes up from $50,000 to $60,000 on March 31st, the original version will show a salary of $50,000 and a new version will be created with an effective date of March 31st and a salary of $60,000.
Effective dating is extremely useful because rather than scrambling to make changes before a payroll date, changes can be done at anytime. Since these changes can be tracked, effective dating also improves auditability (it is easy to see how historical commissions were calculated).
Note: Effective dating in Xactly is currently limited to people, positions, hierarchy and relationships. Hopefully a future version of Incent will allow effective dating of other objects such as plans, rules, quotas, etc.
Organizational Management:
Without effective dating, organizational management was a bit tricky in previous versions. Changes in hierarchy and relationships are now much simpler and much cleaner.
Advanced Search:
Advanced searching makes the process of finding the right object or result much quicker. It was also a needed add-on to be able to search for effective dated objects.
I have seen a few minor upgrades of Xactly (3.x) and with the scope of these changes, this new release (version 4) clearly deserves it’s own number. Lets just hope that effective dating will be applicable to all objects in the near future.

Documentation for your new Sales Performance System Integration

January 18, 2008

You have probably heard before how important it is to plan a software solution before beginning its implementation. If nobody told you, here it is: it is EXTREMELY important to plan before you implement. That’s a rule applying to every software development and integration. What do I mean by plan exactly; well one major facet of planning that is often overlooked is the documentation of the project. The biggest challenges with documentation is that the documents often get out of date, people often see documentation is an overhead and a waste of time and money, and project managers may lack experience in implementing applications and don’t know which documents are required.

I am including here a list of some of the documents you should be asking for if they are relevant to your project:

Business Requirements
This document defines all the requirements of the application; everything that the application needs to be able to perform. This is important because acceptance testing is based on how the application performs in relation to its requirements.

Technical Requirements
This document defines technical requirements for the application such as security, response time, etc.

External (functional) Design documents
These documents are probably the most important documents of all. They describe how the application works, what it does, the logic involved, flow charts, and all elements (rules, formulas, lookup tables, rate tables, hierarchies, etc) used to implement the compensation plan.

Internal (technical) Design documents
These documents elaborate on the functional design documents and describe technically how the application will work. Programmers use the technical designs to develop the application. The level of detail should be such that the programmer’s role is only to code what is specified in the document, leaving little for the imagination (i.e. variable names, database objects, etc should all be specified).

Change Request document
It is important to obtain all change requests since the initial requirements in order to understand the current state of the application.

Quality Assurance Plan
This document describes in detail how the application is being tested. It illustrates how different test phases will be performed. Some of these phases include unit testing, system testing, integration testing, and regression testing.

Test documents
Test documents consist of detailed test plans for each test phase described in the quality assurance plan. There should be detailed steps on how to perform every scenario being tested. Test data used for testing should also be provided and documented

Programming/Customization guidelines and standards
A set of guidelines, rules, standards and best practices used when developing the application should be provided.

Data models of databases
The data model shows the relationship between all database tables and attributes. In the case of the implementation of a packaged solution, all custom tables and custom fields should be documented.

Data Dictionary
The data dictionary should include a precise definition of data elements, user names, roles and privileges, Schema objects, Integrity constraints, stored procedures and triggers, and general database structure. In my opinion this is one of the most important document in a project with a heavy data integration component. The definition of the data elements should explain what the element is, where it comes from, how it is generated, what is its general structure and type, list exceptions, etc.

Deployment Procedures
The deployment procedures document describes the method for deploying the application. In the case of a packaged solution, it should list the correct files and versions to deploy, as well as any dependencies or order requirements.