Dears,
***This is the concluding part of my earlier blog article***
6 Ability to differentiate CRM Projects
A Siebel application is usually intended to be used by one of the following groups:
• Users selling high value products to a relatively small number of customers.
• Users dealing with low value, high volume sales and/or service type transactions.
A particularly common mistake resulting from a lack of Siebel expertise is the failure
to recognize the significant difference between these two types of project. Low value, high volume sales and service environments are typically very transactional with emphasis on users gathering set pieces of information in a set sequence, and the style of user interface built needs to reflect this.
By contrast, the nature of transactions in a high value, low volume scenario means that processes are typically quite unstructured, with skeletal information about new opportunities being fleshed out throughout the sales process. It is therefore difficult to predict the sequence in which users will navigate through Siebel and enter information, and again the user interface must reflect this.
Furthermore, high value, low volume sales users can effectively boycott the application if they do not like it – organisations do not fire their top performing salespeople simply because they will not use Siebel. Additionally in this situation, increased management control is often a key stated objective of the Siebel project. However, if this is the sole objective of the project then end users may feel that the system’s only impact on their day-to-day activities will be a negative one. Consequently, user adoption will be poor and the project will fail.
The key is to encourage user adoption by offering genuine benefits for the sales force, such as the provision of up to date competitor analysis, or automatic generation of presentations, proposals and quotations. An application that is well designed for one type of scenario rarely suits the other.
Misunderstanding the user types and consequently not designing the user interface correctly is an expensive mistake to rectify later, not only in terms of build cost but also in terms of lost user confidence when an inappropriate application is deployed.
7 Lack of sufficient knowledge in development team
Configuring Siebel quickly and efficiently is not an impossible challenge but it is a specialist
job. Whereas with many programming languages an expert might work two or even three times as fast as an average programmer, with Siebel development the factor is much bigger, maybe as large as 20. A development team with an inadequate skill set risks delivering any of the following:
• An application that does not meet users’ requirements because the people performing the configuration do not know what is possible or how to implement it.
• An application that was expensive to develop because it contains more configuration than necessary to achieve a given task, in particular extensive coding to implement something that could have been handled far more easily in Siebel Tools if the developer had had the relevant knowledge.
• Following on from the previous point, an application that is difficult and costly to support, enhance and upgrade.
8 Insufficient or inappropriate testing
It is not necessary to spend an excessive amount of time checking the standard features
of the packaged Siebel application, which can usually be assumed to work correctly.
Pre-deployment testing must instead focus on the specific configuration that has been carried out to meet the organization’s particular requirements. Ensuring that the application supports the business processes as intended, and that processes run correctly across multiple applications, is also vital. The trick is to use the limited time period available for testing in the most effective
way possible, concentrating on the areas of highest risk and/or those with the most impact if
there is a problem. This usually means focusing on the following:
• Do the processes, as defined in the workshops, work as anticipated? If a good job has been done of involving users through the design and development process, this should not normally be a major area of concern.
• Are any exceptions to those processes supported?
• Do integrations work between applications?
• Is all the master data, e.g. list of values, correct? Do the initial data loads import all the data correctly?
• Will the application work correctly in the production environment? For example, the development environment might sit on a single LAN, but multiple firewalls might be involved in the production environments that require opening of ports and other infrastructure changes.
• Do any specialist modules, e.g. Siebel Remote, work as expected?
• Will the application work with production volumes? As it can be very difficult to replicate production usage scenarios, careful thought ought to be given to whether this style of testing is necessary and practical and, if so, what scenarios will be simulated.
Test plans are also advisable to ensure a degree of repeatability, although these should be as brief as possible to keep the emphasis on high quality testing, not on the maintenance of test plans.
9 Poor user adoptions
It is not uncommon to come across Siebel implementations that are, in the main, technically sound and well aligned to user requirements, but are poorly adopted because the users do not understand how to take advantage of the facilities offered. This lack of knowledge can and does occur
at multiple levels:
• Not knowing how to perform basic navigation, search and data entry: for example, taking multiple actions to achieve something that can actually be done with a couple of button clicks.
· One of the main causes of this is poor training. The training provided may simply be insufficient, or it may be inadequate in that it only covers the mechanics rather than the procedures specific to the organization. Training that is not delivered very close to the point of system deployment, or training that does not reflect a person’s prior technical experience, will also not yield the best results. For example, it would not be appropriate to use the same training material for a field sales person who has previously hardly used a computer, and a technically literate power user. However, both of these users still have training needs. Surprisingly often, projects get as far as the end user training and deployment stage before it is discovered that the detailed procedures for using the system have not been fully agreed and documented. This lack of clarity is another reason why users do not use the system that has been developed. The normal cause of this is insufficient user involvement throughout the project and it is often one manifestation of more deep seated problems in an implementation. To avoid delivering a system which users cannot use to its full potential, it is essential to thoroughly plan the way in which the application will be used, and to provide adequate training to users across the organization.
10 Inadequate reporting
When designing and configuring a Siebel application, it is easy to focus entirely on the entry of data, and how that data should be transferred to other applications by integration. However, in most implementations, a key requirement is to extract data from the application and put it in a form that
managers at all levels can use to make decisions. In other words, the application must have the capability to report on and analyze information held in the database. Oracle provides a number of reporting and analysis tools including Siebel Reports (Actuate), Oracle BI Publisher and Oracle
Business Intelligence Enterprise Edition (Siebel Analytics). The most suitable tool depends on the situation, and it is often appropriate to meet multiple requirements with multiple technologies.
It is essential to consider reporting at the start of a project, to ensure that the information captured suits the reporting requirements, and to ensure that reporting and analysis are delivered either in parallel with, or very shortly after, the main Siebel releases. If any of these steps are omitted,
an otherwise excellent Siebel implementation can elicit a reaction of “so what?” from the business community.
Common Theme : Product Excellence
The majority of the problems outlined here are underpinned by a common theme. If the project team does not understand Siebel well enough from a functional and/or technical perspective then it is very unlikely that the system will be well aligned to users’ needs, of reasonable technical quality and cheap to create.
Product knowledge cannot be measured in years of experience. It is quite possible for an individual to have worked with Siebel for several years without actually having learnt a great deal about the product. In fact, true product knowledge encompasses three key things:
• A thorough understanding of what the core product does and how that can be applied to particular business situations.
• A deep comprehension of the principles behind how the product is built. It is not possible to hold the entirety of such a vast product inside one person’s head, but it is perfectly possible to have a firm enough understanding of the underlying technologies to allow any new functional area to be learnt very quickly.
An understanding of how to gently bend the core product to any given business situation and, in particular, which of the multitude of available configuration techniques is most applicable in which situation. Projects may have effective team members who have either a strong functional or technical emphasis in their skill set, but a truly worthwhile team member will have knowledge about both dimensions.
In our experience, the most successful Siebel projects have a small team of experts who can both speak to users about requirements and effectively configure Siebel to meet those requirements. The value of real product knowledge (as opposed to certificates or years of poor quality experience) cannot be overestimated.
In conclusion
A Siebel project has the potential to increase an organization’s sales, improve customer service and reduce internal costs. However, without adequate effort, planning and expertise, the project can run into a number of problems, and ultimately fail to deliver on expectations.
“To achieve success, it is essential that your project team is equipped with the skills and resources, both internal and external, that they need to maximize the benefits of this powerful software suite.”
Your Partner and Companion
A Siebel application is usually intended to be used by one of the following groups:
• Users selling high value products to a relatively small number of customers.
• Users dealing with low value, high volume sales and/or service type transactions.
A particularly common mistake resulting from a lack of Siebel expertise is the failure
to recognize the significant difference between these two types of project. Low value, high volume sales and service environments are typically very transactional with emphasis on users gathering set pieces of information in a set sequence, and the style of user interface built needs to reflect this.
By contrast, the nature of transactions in a high value, low volume scenario means that processes are typically quite unstructured, with skeletal information about new opportunities being fleshed out throughout the sales process. It is therefore difficult to predict the sequence in which users will navigate through Siebel and enter information, and again the user interface must reflect this.
Furthermore, high value, low volume sales users can effectively boycott the application if they do not like it – organisations do not fire their top performing salespeople simply because they will not use Siebel. Additionally in this situation, increased management control is often a key stated objective of the Siebel project. However, if this is the sole objective of the project then end users may feel that the system’s only impact on their day-to-day activities will be a negative one. Consequently, user adoption will be poor and the project will fail.
The key is to encourage user adoption by offering genuine benefits for the sales force, such as the provision of up to date competitor analysis, or automatic generation of presentations, proposals and quotations. An application that is well designed for one type of scenario rarely suits the other.
Misunderstanding the user types and consequently not designing the user interface correctly is an expensive mistake to rectify later, not only in terms of build cost but also in terms of lost user confidence when an inappropriate application is deployed.
7 Lack of sufficient knowledge in development team
Configuring Siebel quickly and efficiently is not an impossible challenge but it is a specialist
job. Whereas with many programming languages an expert might work two or even three times as fast as an average programmer, with Siebel development the factor is much bigger, maybe as large as 20. A development team with an inadequate skill set risks delivering any of the following:
• An application that does not meet users’ requirements because the people performing the configuration do not know what is possible or how to implement it.
• An application that was expensive to develop because it contains more configuration than necessary to achieve a given task, in particular extensive coding to implement something that could have been handled far more easily in Siebel Tools if the developer had had the relevant knowledge.
• Following on from the previous point, an application that is difficult and costly to support, enhance and upgrade.
8 Insufficient or inappropriate testing
It is not necessary to spend an excessive amount of time checking the standard features
of the packaged Siebel application, which can usually be assumed to work correctly.
Pre-deployment testing must instead focus on the specific configuration that has been carried out to meet the organization’s particular requirements. Ensuring that the application supports the business processes as intended, and that processes run correctly across multiple applications, is also vital. The trick is to use the limited time period available for testing in the most effective
way possible, concentrating on the areas of highest risk and/or those with the most impact if
there is a problem. This usually means focusing on the following:
• Do the processes, as defined in the workshops, work as anticipated? If a good job has been done of involving users through the design and development process, this should not normally be a major area of concern.
• Are any exceptions to those processes supported?
• Do integrations work between applications?
• Is all the master data, e.g. list of values, correct? Do the initial data loads import all the data correctly?
• Will the application work correctly in the production environment? For example, the development environment might sit on a single LAN, but multiple firewalls might be involved in the production environments that require opening of ports and other infrastructure changes.
• Do any specialist modules, e.g. Siebel Remote, work as expected?
• Will the application work with production volumes? As it can be very difficult to replicate production usage scenarios, careful thought ought to be given to whether this style of testing is necessary and practical and, if so, what scenarios will be simulated.
Test plans are also advisable to ensure a degree of repeatability, although these should be as brief as possible to keep the emphasis on high quality testing, not on the maintenance of test plans.
9 Poor user adoptions
It is not uncommon to come across Siebel implementations that are, in the main, technically sound and well aligned to user requirements, but are poorly adopted because the users do not understand how to take advantage of the facilities offered. This lack of knowledge can and does occur
at multiple levels:
• Not knowing how to perform basic navigation, search and data entry: for example, taking multiple actions to achieve something that can actually be done with a couple of button clicks.
· One of the main causes of this is poor training. The training provided may simply be insufficient, or it may be inadequate in that it only covers the mechanics rather than the procedures specific to the organization. Training that is not delivered very close to the point of system deployment, or training that does not reflect a person’s prior technical experience, will also not yield the best results. For example, it would not be appropriate to use the same training material for a field sales person who has previously hardly used a computer, and a technically literate power user. However, both of these users still have training needs. Surprisingly often, projects get as far as the end user training and deployment stage before it is discovered that the detailed procedures for using the system have not been fully agreed and documented. This lack of clarity is another reason why users do not use the system that has been developed. The normal cause of this is insufficient user involvement throughout the project and it is often one manifestation of more deep seated problems in an implementation. To avoid delivering a system which users cannot use to its full potential, it is essential to thoroughly plan the way in which the application will be used, and to provide adequate training to users across the organization.
10 Inadequate reporting
When designing and configuring a Siebel application, it is easy to focus entirely on the entry of data, and how that data should be transferred to other applications by integration. However, in most implementations, a key requirement is to extract data from the application and put it in a form that
managers at all levels can use to make decisions. In other words, the application must have the capability to report on and analyze information held in the database. Oracle provides a number of reporting and analysis tools including Siebel Reports (Actuate), Oracle BI Publisher and Oracle
Business Intelligence Enterprise Edition (Siebel Analytics). The most suitable tool depends on the situation, and it is often appropriate to meet multiple requirements with multiple technologies.
It is essential to consider reporting at the start of a project, to ensure that the information captured suits the reporting requirements, and to ensure that reporting and analysis are delivered either in parallel with, or very shortly after, the main Siebel releases. If any of these steps are omitted,
an otherwise excellent Siebel implementation can elicit a reaction of “so what?” from the business community.
Common Theme : Product Excellence
The majority of the problems outlined here are underpinned by a common theme. If the project team does not understand Siebel well enough from a functional and/or technical perspective then it is very unlikely that the system will be well aligned to users’ needs, of reasonable technical quality and cheap to create.
Product knowledge cannot be measured in years of experience. It is quite possible for an individual to have worked with Siebel for several years without actually having learnt a great deal about the product. In fact, true product knowledge encompasses three key things:
• A thorough understanding of what the core product does and how that can be applied to particular business situations.
• A deep comprehension of the principles behind how the product is built. It is not possible to hold the entirety of such a vast product inside one person’s head, but it is perfectly possible to have a firm enough understanding of the underlying technologies to allow any new functional area to be learnt very quickly.
An understanding of how to gently bend the core product to any given business situation and, in particular, which of the multitude of available configuration techniques is most applicable in which situation. Projects may have effective team members who have either a strong functional or technical emphasis in their skill set, but a truly worthwhile team member will have knowledge about both dimensions.
In our experience, the most successful Siebel projects have a small team of experts who can both speak to users about requirements and effectively configure Siebel to meet those requirements. The value of real product knowledge (as opposed to certificates or years of poor quality experience) cannot be overestimated.
In conclusion
A Siebel project has the potential to increase an organization’s sales, improve customer service and reduce internal costs. However, without adequate effort, planning and expertise, the project can run into a number of problems, and ultimately fail to deliver on expectations.
“To achieve success, it is essential that your project team is equipped with the skills and resources, both internal and external, that they need to maximize the benefits of this powerful software suite.”
Your Partner and Companion
DC*
No comments:
Post a Comment