Microsoft Dynamics CRM Team Blog: Data Design for CRM Projects - Customisation Approaches

[Blog bot]

Источник: http://blogs.msdn.com/crm/archive/20...pproaches.aspx
==============

Our guest blogger today is CRM MVP David Jennaway, the technical director of Excitation Ltd, a Microsoft Gold Partner in the UK that specializes in delivering Microsoft CRM solutions.

CRM offers a range of options when designing a CRM solution for a customer, from providing a completely standard, ‘out of the box’ solution, to a heavily customised solution where CRM is considered as more of a development platform. In this article I’ll discuss the broad customisation approaches, and examples of their use.

Preamble

Before getting into detail, I think it’ll be useful to explain my aims behind this post:

I have recently been spending time building design patterns based on direct and indirect experience of around 100 customer implementations of Dynamics. The primary aim of these design patterns is to be able to apply the experience gained as a company from these implementations to future implementations. The areas covered in this post form a basis for identifying approaches that can be taken, and the factor that influence some of the decisions.

This post is primarily concerned with what I term ‘data design’ – i.e. deciding on the data structures (as implemented by CRM entities, relationships and attributes), and the major functionality required of the design.

Don’t expect black and white conclusions from this post. A common theme is that many approaches are possible, and an overall design typically incorporates several approaches. My main intention is to raise awareness that the different approaches exist, and to focus on what factors should most strongly influence the decisions you take.

What factors affect the design choices

Before getting to the different approaches, we need to consider what factors are most important when comparing different design approaches. Whenever we start a design for a customer, we have to be aware that each customer will put different emphasis on these factors.

Benefits of using existing entities and functionality

There are many benefits to be had from using the built-in CRM entities, and their associated functionality. Little or no development time is required, the functionality is documented in the online help and other training materials, and additional components like the reports that ship with CRM can be used immediately.

Conversely, if you create custom entities, you may need to invest development time to provide specific functionality. You may need to invest time and effort in customising the CRM online help, or developing other training material that describes the custom entities and their use. If you want to report on the custom entities you will have to write new reports, or spend time modifying the built-in reports.

However, you need to decide if the built-in entities and functionality are appropriate for your requirements...

Appropriateness of the solution

A major benefit of having a heavily customisable product like CRM is that it can be customised to meet different companies’ needs. The main reason for customisation is to make the solution appropriate to your business requirements.

It is important to note that there is normally a trade-off between the extent of customisation, and the overhead of creating the customisations. If the built-in CRM entities do not map perfectly to your requirements and existing processes, then you may make the decision to adapt your requirements and/or processes, or you may decide to customise CRM to more closely fit your requirements.

Reusability of custom functionality or designs

3rd party add-ons are a classic example of how custom functionality can be reused, where the 3rd party invests the development effort in creating an add-on, and recoups (or hopes to) the cost by selling it many times.

Companies like ourselves that primarily sell CRM implementation services frequently aim for reuse, though sometimes in a less obvious way. A lot of the custom code we develop is intended for reuse, such that apparently custom functionality may already been developed, and will not need creating from scratch. A large part of my internal company work is around promoting such reuse.

Thinking of the future – maintaining flexibility

Any given design should work for a business in its current state, but what about that business in a year’s time, or 2 years ? Requirements and processes change over time, and you should expect a solution that can accommodate these changes. Some future changes can be predicted, and others can’t, but some customisation approaches result in a more flexible solution than others.

Also consider whether the business requirements and processes are stable, well known and understood at the start of the project. It is quite common for requirements to change during an implementation project, so again flexibility can be important.

Some CRM projects are conceived as a one-off implementation, after which little change is expected. Other projects take a more phased approach, where the overall solution is expected to be extended or modified after the initial implementation. In the latter scenario flexibility is more important.

The customisation approaches

An overall CRM solution often comprises different approaches in different areas of the solution; one approach does not need to be used across the board. For example, we almost always use the Account and Contact built-in entities in a standard way, but are more likely to use custom entities to handle fulfilment areas, using custom entities like Project, or Supplier.

Using built-in entities in a standard way

This is the ideal scenario, providing the built-in entities provide the functionality you want. Some, like the Account and Contact mentioned above, and also the activity entities, most often do provide the functionality you want. You’ll typically add extra attributes and modify the forms and views, but the core functionality is appropriate in most circumstances.

However, there are often cases where the built-in entities don’t work the way you do. You may decide to adapt your processes to fit the standard functionality, but it’s more likely you’ll take a more customised approach...

Extending the functionality of built-in entities

Often the built-in entities provide useful functionality, but it’s not enough. Providing the functionality they provide does not actually interfere, or conflict, with what you want, then it makes sense to extend the built-in entities.

An example here is the sales entities, such as Quote and Order, and the associated Quote Product and Order Product child entities. The functionality around pricing and costs is frequently appropriate, but you may need additional attributes to break down the pricing into different areas on a product. You may then need to develop additional functionality to perform calculations on the data in these attributes.

Creating custom entities in addition to the built-in entities

It is often necessary to extend the CRM schema with new custom entities. Necessarily the examples become quite specific; probably the most common custom entity we create is a Project entity to manage delivery of services.

CRM does provide a fair bit of functionality for custom entities, such as support for workflow and association with activities, but more specific functionality may need to be written.

Creating custom entities to replace to the built-in entities

Sometimes you need functionality similar to that provided by the built-in entities, but it is sufficiently different to what you get out of the box that it becomes more appropriate to create custom entities instead.

This is typically the area where the trade-off between the factors covered earlier is most acute. You may make a decision to incur the additional implementation costs of creating new entities and functionality because the built-in entity functionality is too inappropriate to the way your business works.

An example of this is around the Opportunity and Opportunity Product entities, and the Product Catalog. The Product Catalog is flexible, but does have limitations when selling bespoke products or services, or when anticipated revenue over time periods is important. So, in some circumstances we effectively replace the product catalog and related entities with custom entities (e.g. an Item entity), and provide custom functionality to summarise numeric values across items, or transfer items from an opportunity to a quote or order. We have also gone further still, and replaced the opportunity, quote and order entities with custom entities.

Note that when I use the term replace, I’m referring to what the user sees in CRM. The typical implementation pattern is to remove all permissions from the built-in entities we ‘replace’ so that they don’t appear in the CRM user interface – we don’t actually remove them.

Repurposing built-in entities

There are some scenarios where you don’t need an entity to provide the functionality it was intended for, but that functionality could be used in other ways. As entities can be renamed, and the text of CRM messages can be changed, it is possible to repurpose entities while keeping terminology in the CRM user interface consistent with the terminology used in your business

Any examples tend to be very specific and hence not very useful for a general post like this, but one worth explaining relates to the price list. One feature of the price list is that, when adding products to an opportunity, the products available for selection are those that have items on the selected price list. It is possible to repurpose the price list as a way of grouping products, and restricting what is available for selection, even if you don’t actually use the pricing functionality of the price list.

A potentially significant drawback of this approach is that it can restrict your flexibility to make future design changes – using the above example you may not need the price list now, but how sure can you be that you won’t need it in the future ?

Using 3rd party add-ons or off-the-shelf solutions

The approaches I’ve covered so far come from the premise that your solution is unique. However, there are areas where you can find an existing set of extensions or customisation that are appropriate. Several companies providing CRM implementation services specialise in a particular vertical market (e.g. banking), and can provide a set of standard set customisations that are appropriate to many companies in that market. As this post is concerned with data design, the more relevant example of a 3rd party is a provider of implementation services – if this post were concerned with designing specific functionality then add-on providers would be the more relevant example of a 3rd party.

If using 3rd party customisations then you still have to consider how appropriate they are to your business (to use the above example, not all banks work the same way). You may still need further customisations, and if you have to replace or modify the behaviour of purchased extensions, then the cost may be higher than if you had started from a standard CRM design.

Conclusions

The initial conclusion is that there normally isn’t one answer; it is possible that several approaches can be viable, and as mentioned earlier, most overall solution designs we create use a combination of approaches.

But, I think choice is a good thing, and it’s good to be aware of the alternatives. Ideally, given the relative weighting of the factor discussed earlier, and your specific business requirements, you will adopt the best approach(es) and the best solution, but it is often the case that you can get a successful implementation using one of several different solutions, using different approaches.

My personal view is that it is normally worthwhile customising CRM to meet your specific requirements. The customisation capabilities of CRM are very powerful, and if you have an implementation partner with solid experience customising CRM, then a lot can be achieved for relatively little cost. However, attention does need to be paid to the ramifications of heavy customisation, especially how it affects the training material and user documentation.

Cheers,

David Jennaway



Источник: http://blogs.msdn.com/crm/archive/20...pproaches.aspx