Customer Configuration Updating:Activation and usage
From Wikipedia, the free encyclopedia
This entry is an element of the Method Engineering Encyclopedia of the Utrecht University.
Contents |
[edit] Short introduction to the activation and usage process
The activation and usage process of Customer Configuration Updating (CCU) can be described as the activation of product software and the working of it at the customer’s site. As described in the main CCU entry, this is the last stage of the process.
Figure 1 shows the overall picture of the CCU model. As can be seen, the model is divided into four phases namely: release, delivery, deployment and activation & usage. To clarify this, the phases of CCU that are not covered in this article are concealed by a transparent yellow rectangle.
After releasing, delivering and deploying the software it needs to be activated through a license in order to personalize the software for a specific customer. This is done within the license management at the vendor’s site.
Another part of this process is the feedback part. It’s important for a vendor to know how a customer thinks about the product and what kinds of problems occur when using the software. This also includes customer configuration data and all kinds of questions a customer can have. Feedback management is a way of obtaining and managing this kind of information.
[edit] From deployment to activation and usage
Within the deployment process it’s important to know what the current configuration at the customer’s site is and what resources the customer uses. This is also important in the activation and usage process because licenses have to be adapted to the software configuration or even parts of the software configuration at the customer’s site.
In order to do this, the feedback management plays an important role. By obtaining customer configuration data through feedback, the deployment process for future updates can benefit from this. The data is used to adapt updates and to make sure that the implementation is done with minimal obstruction. After a successful deployment process, activation can take place.
[edit] Customer activation
[edit] Activation request
After the deployment of a software product implementation or update, an activation request is send to the vendor to start the activation procedure. The customer’s contract is used to identify the license type, if a customer already has one. If not, a license is generated in order to link it to a certain license type.
[edit] Licensing
Product software uses licensing to control the software. In this case, the license is a software license which is an agreement between vendor and customer. This agreement is sort of a contract or certificate which states the rights of the customer and the vendor. For example the type of product, the amount of users allowed using the product, for what period of time the license is valid and which part(s) of the software are allowed to be used. It also contains the activation code(s) sent to the customer to activate the product.
In the case of CCU it’s important to manage these licenses automatically in order to renew or prolong a license without much effort.
[edit] License types
Most software packages, used in businesses, can be bought with different license types. This can be a license to use a certain part of a software package or a license for the whole package. These types can then consist of a temporary license to be used for trail purposes or a full operational license.
After the contract has been found in the CRM system and a license type is identified, the actual license is generated. The generated license will then be encoded, to ensure that piracy is kept to a minimum, and stored in a database. In order to activate the customer, the stored license can either be downloaded by the customer who can activate the license himself or be downloaded and activated automatically by the software if it supports this.
A broader look at licensing can be found in a paper by Halina Kaminsky and Mark Perry, called “The Pattern Language of Software Licensing”.
[edit] Delivery report
A delivery report contains al kinds of information about the activation process at the customer’s site. It can contain information about the license type, the time it took to activate the software, the time and date of the activation or other relevant information about the activation of the software. This report is send to the vendor automatically after activation.
[edit] Feedback management
This chapter provides an overview of the activities related to feedback management.
[edit] Why do we need feedback management?
Feedback management consists of all activities related to the acquisition of large amount of data about a customer and the software it uses. The vendor can use this information for product improvement or customer relationship management (CRM) purposes. Up until this day, a lot of software vendors still don’t use this information to its full extend. Therefore it’s important to address the need of this type of information. This feedback is also used in the delivery phase in case of an update.
[edit] Automatic or manual feedback
This method contains two types of feedback:
• Automatic feedback is described as feedback without customer interference. A build in module sends information such as configuration and usage data from the customer to the vendor. This is mentioned in the license agreement and only used for product and service improvements.
• Manual feedback is described as customer triggered feedback sent to the vendor. This feedback can consist in the form of bug reports, user questions or other relevant data about product usage sent by the customer to the vendor.
[edit] Different types of feedback
[edit] Error reports
When the software comes across errors in the program or errors triggered by the user, it can automatically make a report of it and send it to the vendor for product improvement and evaluation purposes. An example of this can be seen in Microsoft Windows XP. When an error has occurred a popup comes op that states the question to send a report to Microsoft for product improvement purposes.
[edit] Bug reports
A vendor can ask its customers to send a bug report when they come across bugs in the software which aren’t registered by the software. This information can then be used for product improvement and evaluation purposes. And helps the vendor to collect problems which aren’t mentioned in the error reports.
[edit] User questions
The software should contain a function to state questions about the software. This can be questions about unclear functions, feature requests or problems with the software.
[edit] Customer configuration data
CCU focuses on the improvement of the product update process. Therefore it needs information about the customer’s configuration like settings, installed modules, installed updates, product versions and other relevant information. This information is called customer configuration data. It will take less time to adjust an update to the customer’s wishes because the information is obtained automatically by the software.
[edit] Product usage data
Another part of the feedback data is the product usage data. It consists of data about the daily usage of the software. For example, it can contain data about the amount of times a certain function is used. This information can then be used to discuss whether a function is still needed or not.
[edit] Analyzing feedback data for product improvement
The gathered feedback is valuable to a vendor. It can help him to improve his product by analyzing the data and learn from it. As stated above the feedback can be used to get to know the customer and its configuration or to acquire bug and error reports, witch help to prevent these problems in a future update. Eventually this will lead to better service and more trust from the customer.
[edit] Process-data diagram
A process-data diagram is used to graphically illustrate the activities and deliverables within the activation and usage process.
The process-model witch is shown on the left side of figure 2, describes the flow through the activities mentioned earlier in this entry. While the data-model shows the deliverables that come out of some of the activities. The data-model is stated on the right. A dotted line is added to show the relation between an activity and the deliverables. The numbers stated in the “data” part (right side), indicate the relation between the deliverables. For example, 1 LICENCE DATABASE can contain multiple activation requests and is states as 1..*.
[edit] Activity table
The activity table states a summary of the activities and its sub-activities used in the process-data diagram (Figure 2). These activities are steps to take in the process of activation and feedback management.
| Activity | Sub-activity | Description |
|---|---|---|
| Activate customer | Receive new product activation request | When a new product is purchased, a new license has to be assigned. A request is send to the license database to start the process. |
| Receive license renewal request | When a customer already has 1 or more licenses it can be the case that one of these licenses has to be renewed. A request is send to the license database to start the process. | |
| Identify customer | In order to activate the right customer, the customer has to be identified in the vendors system. | |
| Identify contract | A customer can have multiple contracts with a vendor. So it’s important to identify the right contract. | |
| Identify license type | Since there can be more than one license it’s important to identify the right license in order to make the activation successful. | |
| Generate license | When a customer has a contract but wants to license a new product or product part a new license has to be generated. | |
| Prolong license | In order to prevent piracy the license has to be encrypted before activation can take place. | |
| Renew license | This is where the license is stored in a database. | |
| Generate license code | A random code is generated by the system and attached to the license | |
| Encode license | In order to prevent piracy the license has to be encrypted before activation can take place. | |
| Store license | After generating a code and linking the license to a customer contract the license is stored in the license database. Now it can be used again to prolong or renew the license in the future. | |
| (Re-)activate customer license | This is where the license is activated by the vendors system. It can now be used at the customers site. | |
| Deliver license + code to the customer | After the license has been activated it can be delivered to the customer. | |
| Use Product | - | After activating the license and delivering it to the customer, the product can be used officially. |
| Feedback management | Get customer feedback | Feedback can come from either automatic sources or manual customer triggered sources. |
| Automatic feedback | Feedback that is obtained automatically (usage and configuration data etc.). | |
| Manual feedback | Feedback that is obtained from customer responds (bugs, questions etc.). | |
| Get customer configuration data | If relevant, the software sends data about a customer’s configuration to the vendor. This data can then be used to make special offers or help a customer when he has problems with the software. | |
| Get error report | If an error occurs in the software this will be noted in a log file. This file will be sent to the vendor so he can see what went wrong. | |
| Get product usage data | All kinds of data about the customer’s usage will be sent to the vendor. This can be information about the amount of time a product or module is used. Or how it acts in the field. | |
| Get bug report | When a customer comes across certain bugs in the software he can report them to the vendor. The vendor can use this information to resolve the problem. | |
| Get user questions | All questions sent in by the customers are gathered. These questions can be about the product but also about certain services etc. | |
| Analyze feedback data | All feedback-data, like bug reports, usage data and questions can be used for product improvement. Therefore, the data has to be analyzed in order to improve the product. |
Table1: Activity table
[edit] Table of concepts
The table of concepts gives the definitions for the deliverables in the data-model on the right side of figure 2. References used in this table are also used for some of the underlined words is this entry.
| Concept | Definition (source) |
|---|---|
| LICENSE DATABASE | Is a database in witch a vendor can store its licenses and its accompanying customers |
| ACTIVATION REQUEST | This is where the user activation starts. After deploying the update at a customers site an activation request is send to the vendor. |
| CONTRACT | Is a "promise" or an "agreement" that is enforced or recognized by the law. In the civil law, contracts are considered to be part of the general law of obligations. (http://en.wikipedia.org/wiki/Contract) |
| SOFTWARE LICENSE | A software license is a type of proprietary or gratuitous license as well as a memorandum of contract between a producer and a user of computer software — sometimes called an End User License Agreement (EULA) — that specifies the perimeters of the permission granted by the owner to the user. |
| LICENSE CODE | This is the software license code which activates the software product. It consists of a string of numbers and letters and corresponds to the license agreement between a vendor and a particular customer. By using this license code, the software automatically identifies the license type corresponding with the contract/agreement. |
| ACTIVATED LICENSE | Product activation is a license validation procedure required by some computer software programs. Specifically, product activation refers to a method where a software application hashes hardware serial numbers and an ID number specific to the product's license (a product key) to generate a unique Installation ID. (http://en.wikipedia.org/wiki/Product_activation) |
| DELIVERY REPORT | Documented results concerning the delivery of the activated license to the customer. |
| PRODUCT SOFTWARE | We define product software as software with accompanying materials sold in a defined. Examples of product software are ERP software, accounting software, word processor, and software development tools. (Platform Product software: http://www.cs.uu.nl/groups/OI/ppsw/content.php?page=welkom.html) |
| FEEDBACK DATABASE | A database witch storages all customer feedback. This can be bug reports, questions, configuration data etc. |
| FEEDBACK | Feedback is a process whereby some proportion or in general, function, of the output signal of a system is passed (fed back) to the input. (http://en.wikipedia.org/wiki/Feedback)
Feedback is often used to improve a certain product or service. In this case it’s the product software. |
| PRODUCT IMPROVEMENT REPORT | All feedback data is collected to make a list of improvements. This total package of feedback is called improvement data because it’s used to fix bugs, adapt UI problems and improve their customer service. |
| CUSTOMER CONFIGURATION DATA | Information about the customer’s configuration. This information is send automatically to the vendor and gives a clear picture of the way a customer has his product set up. |
| PRODUCT USAGE DATA | This data contains information about the actual product usage. This reflects on options that are most used within the product software and how they are used. |
| ERROR REPORT | Is a report containing errors that the software has encountered during usage. When the software product gets an error it will automatically send an error report to the vendor. |
| BUG REPORT | A report of the problems users encountered using the product. This can mean a problem with a certain function or dead links within the system. This information is collected manually. |
| USER QUESTIONS | Questions users have about handling the product etc. |
Table 2: Table of concepts
[edit] Example
This example illustrates the process of activation and usage in the Exact Software company:
Exact Software releases its software through the product updater or an ordered CD. When the software is installed, it can only be used once the Exact Software license file (ELC) has been downloaded from the Exact Software Customer portal. This file states that the software is accessible to the customer and what parts of the software can be used.
After a contract is signed, they upload it into their CRM system. When this is done, the license file can be constructed. Several options have to be selected to meet the requirements stated in the contract. A license file cannot be created if the right options haven’t been selected. The license file is valid if all options and variations are selected. Only then the actual ELC is generated. This is done automatically through a script that runs periodically. After this, the ELC is available on the Exact Software Customer portal.
Exact Software installs the complete software package, even if the customer only bought a part of it. Therefore the ELC-file is used to activate the requested parts of the software. The ELC-file can only be changed by Exact Software and will be overwritten each time an update takes place.
A customer can now download the ELC-file to activate the software.
Some customers buy a product directly from Exact Software, but more often they buy it from a reseller. If a customer encounters problems they get support through Exact Software. They can report bugs and questions to the support department which reports it to the development team. In some cases the reseller gets a special “Service Centre” status which means that the reseller can give support on products made by Exact Software. Whenever a customer has a feature request or reports a bug, the reseller reports it to the support departments. Every three months a new release of the product comes out in which bugs are fixed and feature requests are implemented.
This support cycle repeats itself during the lifecycle of an Exact Software product.
[edit] See also
• Customer Configuration Updating
• Customer Configuration Updating: Release (not created yet)
• Customer Configuration Updating: Deployment
• Customer Configuration Updating: Delivery
• Release Management
• WikiProject: Method Engineering
[edit] References
Jansen, S. & Ballintijn, G. & Brinkkemper, S. (2005). Definition and validation of the key process areas of release, delivery and deployment for product software vendors: turning the ugly duckling into a swan. In Technical Report CWI, 2005.
Jansen, S. & Ballintijn, G. & Brinkkemper, S. (2004). Software release and deployment at Exact. In Report SEN-E0414, 2004.
Jansen, S. & Ballintijn, G. & Brinkkemper, S. & van Nieuwland, A. (2005). Integrated development and maintenance of software products to support efficient updating of customer configurations: a case study in mass market ERP software. International Conference on Software Maintenance 2005.
Carzaniga, A.& Fuggetta, A. & Hall, R. & van der Hoek, A. & Heimbigner, D. & Wolf, A. (1998). A characterization framework for software deployment technologies. In Technical Report CU-CS-857-98, Dept. of Computer Science, University of Colorado, 1998.
