Customer Relationship Management (CRM) RFP Template (FREE sample)
1.
Description: A Customer Relationship Management (CRM) system model embeds modules like Business-to-Business (B2B) CRM, Marketing Automation, Sales Force Automation, Customer Service and Support, Partner Management, Contract Management and Creation, Project and Team Management, Business-to-Consumer (B2C) CRM, Internet Sales, E-Mail Response Management, B2C Analytics and Business Intelligence, ther CRM-Related Application Areas, E-mail marketing, Customer reference, Commission management, Field service, Relationship capital management, Survey software, Sales proposal software, Product and price configuration, Web conferencing, Mobile computing, Channel management, Retail solutions, Technical Functionality and Support, Business Functionality, Technical Functionality, and Ongoing CRM Solution SupportAbstract: Business-to-Business (B2B) CRM. The Business-to-Business (B2B) CRM enables organizations to manage the whole customer/partner lifecycle and rapidly establish a selling channel, whether merely conventional or online through web-based applications (E-Sales)It encompasses modules from marketing automation to project execution, and contract management.. Marketing Automation. Marketing automation crea
1.
Description: A Customer Relationship Management (CRM) system model embeds modules like Business-to-Business (B2B) CRM, Marketing Automation, Sales Force Automation, Customer Service and Support, Partner Management, Contract Management and Creation, Project and Team Management, Business-to-Consumer (B2C) CRM, Internet Sales, E-Mail Response Management, B2C Analytics and Business Intelligence, ther CRM-Related Application Areas, E-mail marketing, Customer reference, Commission management, Field service, Relationship capital management, Survey software, Sales proposal software, Product and price configuration, Web conferencing, Mobile computing, Channel management, Retail solutions, Technical Functionality and Support, Business Functionality, Technical Functionality, and Ongoing CRM Solution SupportAbstract: Business-to-Business (B2B) CRM. The Business-to-Business (B2B) CRM enables organizations to manage the whole customer/partner lifecycle and rapidly establish a selling channel, whether merely conventional or online through web-based applications (E-Sales)It encompasses modules from marketing automation to project execution, and contract management.. Marketing Automation. Marketing automation crea
Get The Data Right
Or, get it before it gets you
Extract from the Gate Methodology article ... "Everyone has heard the horror stories of cost overruns on SAP programmes. While there are a few factors which are outside the control of the programme managers (e.g. business change, funding withdrawn) the majority of the responsibility lies at their door. From the programme managers viewpoint it is essential to get early warning that things are starting to slip. One of the quickest way to lose your job is to surprise your board 4 weeks from go-live with the message that the programme is 6 months late."
This article is intended as a follow-up to the Gate Methodology article. In this one, we take a closer look at data and how it needs to be closely managed during a typical SAP implementation using the ASAP methodology. Why data? Simply because in our experience it is almost always jumps up and bites you towards the sharp end of the programme.
Briefly, we are concerned here with the transferring of legacy data into the new SAP system. The primary activities and the ASAP phase that this occurs in are shown in the table below:
Data Activity
Identify and Locate
SAP Design and Map
Transform, Build & Test
Load
ASAP Phase
Project Prep
Blueprint
Realisation
Go-Live
Identify and Locate
Right from the start of the project you need to decide what data will be required in the new system. Initially this is at a high level (e.g. customers, accounts) but it also needs to identify data which will not be required in the new system (e.g. assets). Typically this would be done as part of the overall scoping activity. In addition to this list of data to be included, and data not required, a good data section of the scope document would include the following for each required data element:
Source system(s) for this data - This needs to be specific. It is not unusual for customers for a single company entity to be stored in more than one legacy system.
Initial estimates of the volumes - Again be specific e.g. 10,000 customers.
Whether an automated conversion is necessary - Typically required for high volume data, however an automated routine might already be available.
To repeat: this needs to occur right upfront, and certainly before the Blueprint can rightfully begin.
Word of warning: If the data cannot be located or (worse) it is located in many places, get someone to decide (in writing) where it will come from.
SAP Design and Map
During the Blueprint phase, the functional analysts will determine where the data will go in the SAP system, and how it will be used within the processes. Giant spreadsheets will emerge which ought to include - for each data element required - at least the following:
All SAP data fields within the element will be used - And this means all. It's quite simple ... if the field is not on the spreadsheet, it will not show up in SAP once the system is live. That usually helps focus the effort.
Then, for each field identified, document the field business rules (for example define what a Plant will be in SAP - is it a factory, a part of a factory, a truck etc) and also the field technical rules (for example 10 characters alphanumeric).
The same needs to be completed for the data as it is found in the legacy system(s) so that the real fun activity - mapping - can begin. Mapping is the seemingly simple task of associating a single field in SAP with one or more fields in the legacy systems. Sometimes it will not be a perfect fit in which case you will need to transform the legacy data to get it to fit. Add a few more columns to your spreadsheet and capture:
Legacy field it maps to
Legacy field business and technical rules
Any transformation required
Once you have completed this, and still within the Blueprint phase, you need to:
Get it signed off - this is a very big step as data is at the heart of the SAP system
Confirm the exact number and type of automated conversion programmes required
Write high level functional specs for each of these programmes
Word of warning: data cannot be considered done until the functional process design is done (certainly to a high level). Therefore this will typically occur towards the end of Blueprint.
Transform, Build and Test
If any of the above remains un-decided or (even worse) contested, it is better to delay the start of the Realisation phase as changes are much easier (and cheaper) to make at this stage. Some programmes avoid the nasty details ... and end up paying dearly for it later. Ignore this at your peril.
So, assuming you have identified the data you want, located in legacy and mapped it to SAP, then you are ready to:
Transform the data as required - This includes creating non-existent data from scratch, and also altering the legacy data to make it fit into SAP.
Cleanse the data as required. We will only say one thing here. Start this very early. 12 months from go-live is not too early. Cleansing means, for example, get the customer phone number field to contain customer phone numbers, get the stock counts right, eliminate duplication so that one vendor or supplier only appears once.
Build and unit test the data conversion routines.
Build up your tests so that by the end of Realisation you are in effect testing the entire data conversion routine (which might include hundreds of steps). Take note that the data load routines will be inter-connected so that you have to load vendors before you can load open purchase orders, for example.
A word on testing. Even if you get your entire data load suite running perfectly, you will be in for a very nasty surprise unless you integrate it with the functional process testing that should also be occurring towards the end of the Realisation phase. The following is a recommend test checklist:
Have the data conversion programmes been built and unit tested
Have the required manual data related steps been documented, and tested (e.g. data creation)
Have the manual and the automated steps been integrated, and run as a full data conversion suite
Remember - you need to integrate the above with the functional process testing, so assuming the functional process testing been completed (and you are 8 weeks from go-live, or more):
Create a new client
Run your full data conversion suite into it
Then get the functional teams to re-execute their test scenarios using the newly converted data. This is the true test
Repeat until it works
Do not expect this to work first time around. Plan for at least two iterations of this ... each taking 2 weeks.
Load
If all the testing has been successfully completed, you have a minor miracle on your hands and you can face the go-live with confidence. A few last minute reminders would be:
Keep on top of all changes made (or better yet, veto them)
Make sure it is someone's job to execute the data load successfully
Set up a 24 hour control room to stand watch over a 24 hour data load process
Dust off your contingency plan (oops)
Have sufficient functional support people around for 4 weeks post go-live (at least)
Push the button!
As you can see from the above, there are very many things that can go wrong in the data stream of a programme. We have not touched on organisational, skill sets or other people aspects of this. That will be the subject of a future article.
While proper management of the data activities cannot by itself guarantee a successful implementation, at least you will be neutralising one of the greatest dangers to your programme ... and one of the most costly to fix.
Or, get it before it gets you
Extract from the Gate Methodology article ... "Everyone has heard the horror stories of cost overruns on SAP programmes. While there are a few factors which are outside the control of the programme managers (e.g. business change, funding withdrawn) the majority of the responsibility lies at their door. From the programme managers viewpoint it is essential to get early warning that things are starting to slip. One of the quickest way to lose your job is to surprise your board 4 weeks from go-live with the message that the programme is 6 months late."
This article is intended as a follow-up to the Gate Methodology article. In this one, we take a closer look at data and how it needs to be closely managed during a typical SAP implementation using the ASAP methodology. Why data? Simply because in our experience it is almost always jumps up and bites you towards the sharp end of the programme.
Briefly, we are concerned here with the transferring of legacy data into the new SAP system. The primary activities and the ASAP phase that this occurs in are shown in the table below:
Data Activity
Identify and Locate
SAP Design and Map
Transform, Build & Test
Load
ASAP Phase
Project Prep
Blueprint
Realisation
Go-Live
Identify and Locate
Right from the start of the project you need to decide what data will be required in the new system. Initially this is at a high level (e.g. customers, accounts) but it also needs to identify data which will not be required in the new system (e.g. assets). Typically this would be done as part of the overall scoping activity. In addition to this list of data to be included, and data not required, a good data section of the scope document would include the following for each required data element:
Source system(s) for this data - This needs to be specific. It is not unusual for customers for a single company entity to be stored in more than one legacy system.
Initial estimates of the volumes - Again be specific e.g. 10,000 customers.
Whether an automated conversion is necessary - Typically required for high volume data, however an automated routine might already be available.
To repeat: this needs to occur right upfront, and certainly before the Blueprint can rightfully begin.
Word of warning: If the data cannot be located or (worse) it is located in many places, get someone to decide (in writing) where it will come from.
SAP Design and Map
During the Blueprint phase, the functional analysts will determine where the data will go in the SAP system, and how it will be used within the processes. Giant spreadsheets will emerge which ought to include - for each data element required - at least the following:
All SAP data fields within the element will be used - And this means all. It's quite simple ... if the field is not on the spreadsheet, it will not show up in SAP once the system is live. That usually helps focus the effort.
Then, for each field identified, document the field business rules (for example define what a Plant will be in SAP - is it a factory, a part of a factory, a truck etc) and also the field technical rules (for example 10 characters alphanumeric).
The same needs to be completed for the data as it is found in the legacy system(s) so that the real fun activity - mapping - can begin. Mapping is the seemingly simple task of associating a single field in SAP with one or more fields in the legacy systems. Sometimes it will not be a perfect fit in which case you will need to transform the legacy data to get it to fit. Add a few more columns to your spreadsheet and capture:
Legacy field it maps to
Legacy field business and technical rules
Any transformation required
Once you have completed this, and still within the Blueprint phase, you need to:
Get it signed off - this is a very big step as data is at the heart of the SAP system
Confirm the exact number and type of automated conversion programmes required
Write high level functional specs for each of these programmes
Word of warning: data cannot be considered done until the functional process design is done (certainly to a high level). Therefore this will typically occur towards the end of Blueprint.
Transform, Build and Test
If any of the above remains un-decided or (even worse) contested, it is better to delay the start of the Realisation phase as changes are much easier (and cheaper) to make at this stage. Some programmes avoid the nasty details ... and end up paying dearly for it later. Ignore this at your peril.
So, assuming you have identified the data you want, located in legacy and mapped it to SAP, then you are ready to:
Transform the data as required - This includes creating non-existent data from scratch, and also altering the legacy data to make it fit into SAP.
Cleanse the data as required. We will only say one thing here. Start this very early. 12 months from go-live is not too early. Cleansing means, for example, get the customer phone number field to contain customer phone numbers, get the stock counts right, eliminate duplication so that one vendor or supplier only appears once.
Build and unit test the data conversion routines.
Build up your tests so that by the end of Realisation you are in effect testing the entire data conversion routine (which might include hundreds of steps). Take note that the data load routines will be inter-connected so that you have to load vendors before you can load open purchase orders, for example.
A word on testing. Even if you get your entire data load suite running perfectly, you will be in for a very nasty surprise unless you integrate it with the functional process testing that should also be occurring towards the end of the Realisation phase. The following is a recommend test checklist:
Have the data conversion programmes been built and unit tested
Have the required manual data related steps been documented, and tested (e.g. data creation)
Have the manual and the automated steps been integrated, and run as a full data conversion suite
Remember - you need to integrate the above with the functional process testing, so assuming the functional process testing been completed (and you are 8 weeks from go-live, or more):
Create a new client
Run your full data conversion suite into it
Then get the functional teams to re-execute their test scenarios using the newly converted data. This is the true test
Repeat until it works
Do not expect this to work first time around. Plan for at least two iterations of this ... each taking 2 weeks.
Load
If all the testing has been successfully completed, you have a minor miracle on your hands and you can face the go-live with confidence. A few last minute reminders would be:
Keep on top of all changes made (or better yet, veto them)
Make sure it is someone's job to execute the data load successfully
Set up a 24 hour control room to stand watch over a 24 hour data load process
Dust off your contingency plan (oops)
Have sufficient functional support people around for 4 weeks post go-live (at least)
Push the button!
As you can see from the above, there are very many things that can go wrong in the data stream of a programme. We have not touched on organisational, skill sets or other people aspects of this. That will be the subject of a future article.
While proper management of the data activities cannot by itself guarantee a successful implementation, at least you will be neutralising one of the greatest dangers to your programme ... and one of the most costly to fix.
