Dears,
Organisations often spend huge sums on buying and implementing Siebel CRM Applications, and many see a fantastic return on their investment – increasing sales, improving customer service and reducing internal costs. However, others struggle and often become disillusioned with the whole process after years of effort.
Why do Siebel CRM projects go off track, and how can organisations ensure that theirs will be a success?
Siebel CRM is an immensely powerful product with an extremely wide set of functional capabilities. However, it is the way in which the product is implemented that determines whether the anticipated benefits are delivered. A project can fail for a variety of reasons. During our ten years working with Oracle Siebel we have been called on to rescue some projects that have gone off track, and time and time again the cause can be traced to a basic set of problems. By bringing together the ten reasons why a Siebel project is most likely to fail, this blog article examines the factors that separate success from failure.
We explore potential pitfalls and how these can be avoided, and consider how to bring problematic projects back on track. Let see Top 10 Siebel CRM Project Implementation Pitfalls
1 Unrealistic short term expectations
One reason why a Siebel project may be perceived to fail is that there is an unrealistic expectation of how quickly the benefits will be seen. Merely installing Siebel and making it available to users will not transform the effectiveness of an organization. Instead, realizing the full capabilities of the application takes a lot of hard graft from technical and business oriented teams. Time and effort are essential, and not all the benefits will be delivered at once. For example, if a key benefit is more accurate forecasting of sales opportunities, that benefit will not be realized until the organization’s opportunities have been actively managed through the new process and there is consistency in the data. To avoid setting unrealistic expectations, care must be taken to understand at the outset:
• The actual IT costs of the project
• The anticipated benefits and when they are expected to be delivered
• The prerequisite process steps, both technical and business, to obtaining the benefits
• The necessary commitment by the business of time and resources to the project
If adequate consideration is given to these points when developing a project plan, it is possible to celebrate milestones along the way to the ultimate goal, rather than becoming disillusioned by how much work has been done and yet how far there still seems to be to go.
2. Insufficient Siebel knowledge in design team
Experts in the relevant business processes, or experienced business analysts who have worked on other applications, can play vital roles in the analysis and design team, but they must be complemented by real Siebel experts. A lack of Siebel expertise is likely to give rise to the following scenarios:
· Processes are designed based on how non-Siebel applications work, leading to many screens being required for something which could be achieved with one or two button clicks. This leads to significant and often unnecessary reengineering of Siebel.
· Particular ways of working are imposed on the application, when Siebel already supports the exact requirement in a slightly different way. Recreating functionality that exists in the core product is unnecessary and expensive, both in terms of initial development, and of ongoing maintenance, enhancements and upgrades.
· The system fails to meet all the requirements because it is perceived that certain things cannot be achieved in Siebel when in fact, with appropriate skill, they are fairly small configuration tasks. The importance of engaging real Siebel experts at the early stages of a project, with both functional and technical knowledge about what is and is not achievable – and how best to achieve it – cannot be overstated.
3. Separate technical team
In a traditional IT project, a business analyst speaks to users in order to gather requirements, before documenting them and passing them to a technical designer. The designer translates them into a technical design which is then implemented by a programmer before the system is tested and deployed. This approach results in a large gap between the users with the original business problem, and the technical team charged with solving it. In a more extreme version, the development work may even be carried out off-shore. This model may still have a place in some situations but it is not appropriate in a Siebel project. Siebel is different because a skilled configuration expert can bend the core application to meet a particular requirement very quickly. This presents an opportunity to run projects in a way that increases the probability of the delivered system meeting users’ needs, while lowering project costs by reducing the project team size.
The ideal model for a Siebel project is a small, expert team where each individual is responsible for all activities relating to a particular functional area, from requirements gathering, through design, development and testing, to deployment. In larger projects, there may well be people who specialize in design, build or test, or people who are involved in only one area, but the core team should remain throughout the whole project.
4 Insufficient user involvements
Ultimately, a Siebel implementation is a business project that must deliver business benefits. The project is for end users and their managers, so it is critical that they are fully engaged throughout the project to
ensure that the final system delivers what they need. Often, other responsibilities mean that users have only limited time to give to the project, but if they are only prepared to commit very small quantities of time – or even no time at all – then our experience is that a project will not be as successful as it should be. Typically, the most important stages for significant user involvement are:
• In the design phase, including workshops and prototyping to verify that the user interface will support what they need to do. At this stage, it is also important to run through each of the processes that users will perform, to check that nothing is missing.
When planning user involvement, a key consideration is who to involve. This varies from organisation to organisation, and also depends on the task to be performed. Of all the user-centric tasks, design workshops are normally the most critical to a project’s success. Senior management often do not have
enough time to do the activity justice and may not actually understand the finer detail of the processes that users will perform on a day to day basis. On the other hand, running workshops with low level users can result in the collection of information that reflects the details of the current system rather than the changes that senior management are trying to implement. Therefore, the best candidates for these
types of activities are often found at team leader or middle management level.
5 Poorly thought-out integration
Many Siebel implementations involve complex integration with other applications. Even if each individual application that supports a business process is well designed and robust, if the interfaces between those applications are flawed, then the resulting overall system will not be solid. Again, expert Siebel knowledge is essential in this scenario. If the team handling the integration has little Siebel knowledge, the following often occur:
• Inappropriate split of tasks between applications: for example, something that could be easily achieved in Siebel is customized into another application because no one knew better. Unresolved inconsistencies between data models: for example, a contact can have many addresses in Siebel, but only one is supported in a particular legacy application.
• Incorrect interface type selection: the wrong decision is taken over which integration technology (EIM, eAI, Web Services etc) to use. Integration routines may also be poorly developed, since this is primarily a Siebel configuration job requiring expert Siebel skills.
Even when Siebel expertise is engaged in the design and build of integration, organisations often choose to subdivide the Siebel team along the line between configuration and integration. This is a mistake because decisions made at the design stage about how the user interface should work can affect the format, style and frequency of integration – and choices made in integration(often forced by legacy applications) can affect how information should be presented to users. Therefore, the two aspects are by no means independent, and as a minimum, the team building the core configuration should be expert in the issues surrounding integration and vice-versa. Integration must be considered in the context of the overall application design, and not dealt with as an afterthought. Of course, individuals with high levels of expertise in the other applications concerned should also be involved, and collaboration is the key to successful integration projects.
Happy Reading and Watch this space for my concluding Part 2
Your Partner and Companion
DC*
Organisations often spend huge sums on buying and implementing Siebel CRM Applications, and many see a fantastic return on their investment – increasing sales, improving customer service and reducing internal costs. However, others struggle and often become disillusioned with the whole process after years of effort.
Why do Siebel CRM projects go off track, and how can organisations ensure that theirs will be a success?
Siebel CRM is an immensely powerful product with an extremely wide set of functional capabilities. However, it is the way in which the product is implemented that determines whether the anticipated benefits are delivered. A project can fail for a variety of reasons. During our ten years working with Oracle Siebel we have been called on to rescue some projects that have gone off track, and time and time again the cause can be traced to a basic set of problems. By bringing together the ten reasons why a Siebel project is most likely to fail, this blog article examines the factors that separate success from failure.
We explore potential pitfalls and how these can be avoided, and consider how to bring problematic projects back on track. Let see Top 10 Siebel CRM Project Implementation Pitfalls
1 Unrealistic short term expectations
One reason why a Siebel project may be perceived to fail is that there is an unrealistic expectation of how quickly the benefits will be seen. Merely installing Siebel and making it available to users will not transform the effectiveness of an organization. Instead, realizing the full capabilities of the application takes a lot of hard graft from technical and business oriented teams. Time and effort are essential, and not all the benefits will be delivered at once. For example, if a key benefit is more accurate forecasting of sales opportunities, that benefit will not be realized until the organization’s opportunities have been actively managed through the new process and there is consistency in the data. To avoid setting unrealistic expectations, care must be taken to understand at the outset:
• The actual IT costs of the project
• The anticipated benefits and when they are expected to be delivered
• The prerequisite process steps, both technical and business, to obtaining the benefits
• The necessary commitment by the business of time and resources to the project
If adequate consideration is given to these points when developing a project plan, it is possible to celebrate milestones along the way to the ultimate goal, rather than becoming disillusioned by how much work has been done and yet how far there still seems to be to go.
2. Insufficient Siebel knowledge in design team
Experts in the relevant business processes, or experienced business analysts who have worked on other applications, can play vital roles in the analysis and design team, but they must be complemented by real Siebel experts. A lack of Siebel expertise is likely to give rise to the following scenarios:
· Processes are designed based on how non-Siebel applications work, leading to many screens being required for something which could be achieved with one or two button clicks. This leads to significant and often unnecessary reengineering of Siebel.
· Particular ways of working are imposed on the application, when Siebel already supports the exact requirement in a slightly different way. Recreating functionality that exists in the core product is unnecessary and expensive, both in terms of initial development, and of ongoing maintenance, enhancements and upgrades.
· The system fails to meet all the requirements because it is perceived that certain things cannot be achieved in Siebel when in fact, with appropriate skill, they are fairly small configuration tasks. The importance of engaging real Siebel experts at the early stages of a project, with both functional and technical knowledge about what is and is not achievable – and how best to achieve it – cannot be overstated.
3. Separate technical team
In a traditional IT project, a business analyst speaks to users in order to gather requirements, before documenting them and passing them to a technical designer. The designer translates them into a technical design which is then implemented by a programmer before the system is tested and deployed. This approach results in a large gap between the users with the original business problem, and the technical team charged with solving it. In a more extreme version, the development work may even be carried out off-shore. This model may still have a place in some situations but it is not appropriate in a Siebel project. Siebel is different because a skilled configuration expert can bend the core application to meet a particular requirement very quickly. This presents an opportunity to run projects in a way that increases the probability of the delivered system meeting users’ needs, while lowering project costs by reducing the project team size.
The ideal model for a Siebel project is a small, expert team where each individual is responsible for all activities relating to a particular functional area, from requirements gathering, through design, development and testing, to deployment. In larger projects, there may well be people who specialize in design, build or test, or people who are involved in only one area, but the core team should remain throughout the whole project.
4 Insufficient user involvements
Ultimately, a Siebel implementation is a business project that must deliver business benefits. The project is for end users and their managers, so it is critical that they are fully engaged throughout the project to
ensure that the final system delivers what they need. Often, other responsibilities mean that users have only limited time to give to the project, but if they are only prepared to commit very small quantities of time – or even no time at all – then our experience is that a project will not be as successful as it should be. Typically, the most important stages for significant user involvement are:
• In the design phase, including workshops and prototyping to verify that the user interface will support what they need to do. At this stage, it is also important to run through each of the processes that users will perform, to check that nothing is missing.
When planning user involvement, a key consideration is who to involve. This varies from organisation to organisation, and also depends on the task to be performed. Of all the user-centric tasks, design workshops are normally the most critical to a project’s success. Senior management often do not have
enough time to do the activity justice and may not actually understand the finer detail of the processes that users will perform on a day to day basis. On the other hand, running workshops with low level users can result in the collection of information that reflects the details of the current system rather than the changes that senior management are trying to implement. Therefore, the best candidates for these
types of activities are often found at team leader or middle management level.
5 Poorly thought-out integration
Many Siebel implementations involve complex integration with other applications. Even if each individual application that supports a business process is well designed and robust, if the interfaces between those applications are flawed, then the resulting overall system will not be solid. Again, expert Siebel knowledge is essential in this scenario. If the team handling the integration has little Siebel knowledge, the following often occur:
• Inappropriate split of tasks between applications: for example, something that could be easily achieved in Siebel is customized into another application because no one knew better. Unresolved inconsistencies between data models: for example, a contact can have many addresses in Siebel, but only one is supported in a particular legacy application.
• Incorrect interface type selection: the wrong decision is taken over which integration technology (EIM, eAI, Web Services etc) to use. Integration routines may also be poorly developed, since this is primarily a Siebel configuration job requiring expert Siebel skills.
Even when Siebel expertise is engaged in the design and build of integration, organisations often choose to subdivide the Siebel team along the line between configuration and integration. This is a mistake because decisions made at the design stage about how the user interface should work can affect the format, style and frequency of integration – and choices made in integration(often forced by legacy applications) can affect how information should be presented to users. Therefore, the two aspects are by no means independent, and as a minimum, the team building the core configuration should be expert in the issues surrounding integration and vice-versa. Integration must be considered in the context of the overall application design, and not dealt with as an afterthought. Of course, individuals with high levels of expertise in the other applications concerned should also be involved, and collaboration is the key to successful integration projects.
Happy Reading and Watch this space for my concluding Part 2
Your Partner and Companion
DC*
No comments:
Post a Comment