CRM Solutions of Choice Siebel and Salesforce A

CRM Solutions of Choice: Siebel and Salesforce A Development Perspective Varsha Indurjith

• Why are we discussing Salesforce? – To make an Informed Decision when changing or choosing technologies – Be aware of the functionalities of each – What’s the hype about ! – Offer better advise to your client or company – The Inside Story!

• What IS Salesforce? – Cloud computing, Leading edge technology – Software as a Service. No DB, Server, multiple physical environments – Entire infrastructure is hosted and accessed via url – Configuration may be done on ad hoc basis directly on prod without downtime – Clients range from 1 -man shop to large corporate – Simple, easy to use. Makes sense to a non-technical person • What is Siebel? – Established CRM product which 22 specialised industry applications – Tailored industry requirements available Out of the Box – Capable of delivering highly customizable business and end user requirements

The Dilemma: Which CRM product to choose for YOUR organization ? ? ? • Q: What do you want out of your CRM app? • Q: What are you looking to achieve? • Q: Are you happy to adapt to the system? Or do you need the system to adapt to your business? • Q: Are your processes fairly static, or can they be changed to accommodate? Each organization wants something different out of their CRM system, and each organization’s strategy is different. Your application must suit your needs accordingly!

Goal of this presentation: • NOT to sing the praises of any one technology! • IS to highlight some key differences in development capabilities between both, from a developer’s perspective • This uncovers to what extent functionality may be achieved • If you know the building blocks you have to work with, you know what building you’re allowed to construct!

Comparison: Development Environment Siebel • Siebel Tools • Fast to navigate • Independent of network connectivity • Can Develop locally • Requires training to be able to use • Changes need to be compiled before they can be tested Salesforce • No separate dev environment – Setup section in the application available to Administrators • Seamless testing of development – no executable required to be compiled • Only as fast as network connectivity – hyperlinked • Need internet connection to develop

General Configuration Siebel Salesforce • Config definitions visible at a glance – can immediately see updates as of date/time • Numerous design approaches to achieve a requirement – User properties, WF, BC Events, Smartscripts, etc. • Highly customizable • Prone to over-customization – unstable, complicated system. Difficult to use • • Quick to configure Wizard driven Fast turnaround times Quick customization vs wellthought of requirements – because of ease and speed, Analysis/Design steps usually skipped • Cannot see updated items at a glance • Standard fields not customizable

Workflow Siebel Salesforce • Can invoke highly tailored functionality using Business Services • Can achieve complex coded functionality, logical operands, cross-object accessibility • No restriction on number of emails sent out • Does basic actions: field updates, email, create/assign tasks, outbound API messages, time-dependant actions • Very little room for customization – cannot invoke coded functionality • Recursive WF may only be executed a set number of times • Email notifications may only be sent up to 3 x per record • Cross object functionality very limited - std. Vs custom

Validation Siebel Salesforce • Validation rules are sequenced to facilitate priority of execution • No limitation on Boolean evaluations • May not set order of execution, as rules are randomly executed there is no way of defining a sequence of execution • Limited in the combination of AND and OR operands in your rule eg. You may not have (x AND y AND (a OR b)); • Read the fine print!

View layout Siebel • Allow for instant Parent. Child visibility without losing context of either component • Displays fields from cross object components easily, via joins, MVGs, calc fields • Unable to open additional views in new tab and have multiple views available at once for viewing Salesforce • • • drag and drop fields and related lists Extremely easy to customize Page may only display fields from that specific component Information from other components may only be displayed via Related List sections. User has to drill into the record to see all the information on that component. Alternative is to use Visual. Force pages, which are html based pages using Controller class that invoke Apex code. However this requires ongoing maintenance and support Formula field may retrieve cross object information, however they are not visible in all modes of the view

Calculated/Formula Fields Siebel • Can create any number of calculated fields • Character length limitations may be overcome by combining numerous calculated fields to evaluate your condition • No restriction on total character length per component • Used only for computing information – joins and MVGs used for cross-object retrieval • Various standard configuration eg. User properties, may not be performed on a calculated field eg. On Field Update Salesforce • • • Formula fields enable retrieval of cross-object info. There are numerous limitations/governor limits: 4000 char limit on a formula, included chars used in referenced formula fields, spaces and carriage returns 5000 char limit on the compiled size of the formula 32000 char limit on the entire sql statement for a component, including standard, custom and formula fields Formulas cannot reference themselves eg. X = x+y

Audit Trail Siebel Salesforce • Any field on any component may be selected for audit tracking • Holistic view of all updates made, allowing for ease of querying • Reporting may be done on the Audit Trail • Very basic functionality – not every field may be selected for audit + limit on # of fields • Certain components eg. User, may not be enabled for Audit • There is no consolidated view for audit trail across the application – audit trail is displayed as a related list on each page, with only information on that page • Reporting on audit trail not supported

Data Manipulation Siebel • Runtime business services or Business Service Methods may be used for complicated data uploads/data moves – crossobject updates • EIM is required for bulk data uploads. This is quite intensive, and requires specialist skills • Updates done directly on the database is not the recommended route, however is the most used means for simple data updates • Updates done via EIM/Business services is time consuming Salesforce • • Dataloader allows for easy mass updates of data per component Administrator can use for routine updates as well as mass uploads Processes thousands of records per minute Simplifies reassignment processes, employee transfer protocols etc. does not allow for cross-object updates Will not execute if SOQL limits are reached, due to formula fields, triggers (code) etc. Data may easily be deleted if administrator is not aware of the implications of actions

Batch Processing Siebel Salesforce • Batch Workflow jobs • Depending on the server capacity and/or load balancing, workflows may be scheduled in the same time slots • Multiple components may be updated within a single workflow • Batch workflow dependencies may be accommodated • Batch Apex Code • Only up to 5 batch jobs may be processed within an hour • Batch times are per hour only • Each batch job may only process updates on one component. • No standard way to specify dependency on batches

Batch Processing Siebel Salesforce • No limitation on number of emails that is permitted to be sent out • Highly complex logic may be effected in the BS invoked from the workflow • Parent/child records may be processed without a restriction on # of records in child or parent • Emails sent out from any form of coded functionality is limited to 1000 in total for the day • Single SQL statement is used to fetch the recordset to be processed. Only one logical process may be effected on the recordset • Up to 1000 records on parent object retrieved, but >1000 on child is ignored

Smartscript Functionality Siebel Salesforce • Standard functionality; • Can be highly customized using e. Script • Simple enough for an administrator to create • Is not available in Salesforce • Poses a challenge for clients that require fast capture times, eg. Call Centre • May use Visual. Force pages, but these need to be maintained

Events / Triggers Siebel Salesforce • Numerous events on both component and GUI layers • Covers field manipulation, record manipulation, Save/Delete/Update operations, GUI functions – extensive in what can be manipulated • Triggers, limited to standard events such as: Before. Update, Before. Insert, After. Update, After. Insert • Various governor limits around the use of Triggers, Apex code, batch jobs etc. Need to be aware of these prior to designing a solution • SOQL limit -100 per component.

Events / Triggers Siebel Salesforce • No specific limit for total storage allocated for code • Best Practices rather than restricted capabilities • Any DML statement is regarded as a SOQL query: – – – – – delete and database. delete find. Similar insert and database. insert merge rollback run. As set. Save. Point update and database. update upsert and database. upsert • Max amount of code used by all Apex scripts in the organization = 2 MB

Reporting Siebel Salesforce • Actuate – complicated to learn and implement • Static – cannot be modified easily • Other reporting tools may need to be used – BI Publisher, Cognos, Analytics etc. – Cost implication • Built in reporting wizard allows easy creation of reports • Simple enough for end users to create and draw up own reports – in theory! • Need technical understand to choose the correct fields – frustrating for end users • Generally do not allow end users to draw their own reports due to complexity

Reporting Siebel Salesforce • High end functionality but requires a skilled resource • Can only report on parentchild-grandchild relationship – cannot have parentchild 1+child 2 structure • Cannot report on a related list based on a standard component

A Walkthrough • Let’s consider a real-life Development cycle • How does each CRM application deal with the various challenges at each stage of development? • Goal of development: to efficiently, dynamically and accurately incorporate new requirements, whilst maintaining the system’s Stability, Robustness and Reliability

Dev commences, with a combination of consultants and perm employees in varying degrees of skills set – junior to senior. Siebel Salesforce • Developer creates a local database • No limit to how many local databases may be created. Dependency on login accounts on server Database • Salesforce has ‘Organizations’ or ‘Sandboxes’, which is equivalent to an environment, eg. Dev, UAT, etc. • Approx 33 orgs/developer environments may be created, excluding Prod and UAT orgs. – Unlimited Edition

Access to configuration definitions Siebel Salesforce • Structured check in/check out process • Developer works on the configuration locally, tests, then checks back into the server • Other developers cannot access incomplete configuration as it is only checked in on completion • No local/server concept • All developers work off the same connection (server) – Dev A has work in progress, Dev B has work in progress. – Both see each other’s incomplete configuration. • High risk of overwriting configuration; creating duplication; dev A’s bugs will affect Dev B, impeding continuation of work • Communication is crucial

Unit Testing Siebel Salesforce • Conventional – compile, log into local client, test • Would require separate login access as other test users to test for different levels of application access • Extremely fast and convenient • No compiling required. • May log in as any other user of the system and test as them – Grant Admin Access • Can immediately see what pages would look like from any other user’s point of view even while developing

Major changes required during Dev – how to identify changes made and rollback development ? Siebel Salesforce • Changed flag indicates any updates made – list view • Can query on ‘last updated by’ to get developer history • Flat tab enables cross-object searching • Comments field on all definitions • ‘Changed flag’ concept not available • Querying within Setup section not supported. Will have to Sort the records and scroll through pages • Not all definitions allow for a comment to be captured • Manually review definitions, per record, to determine changes made

Major changes required during Dev – how to identify changes made and rollback development ? Siebel • Import of backed up archives, repository, local database, etc to rollback changes made • Redo Check Out to refresh local definitions • Regular backups of local database, to prevent corruption and loss of entire environment Salesforce • • Cannot rollback. Manually undo Eclipse backup – definitions are merged, not overwritten May only abandon the org and start on a new one – lose in-progress functionality Cannot make a backup of configuration done on an org, or backup an org. May only clone an org (max of approx 33) Cannot version control reliably– Eclipse may be used to a limited extent Major changes eg. Redesign usually results in scrapping the environment and starting over in a new org as this is quicker than identifying all the changed components Documentation is crucial for tracking development changes

Change of requirements during UAT – redesign, major or minor changes. Ease of change to dev environment? Siebel Salesforce • Export/import repository keeps environments in sync – reliable and efficient process – does not leave things to chance • Archives allow for individual definitions to be backup up/refreshed • Impact on timelines minor • Same as above. However added complication is that now there are 2 orgs involved • Keeping both in sync is a manual process – combination of Cloud Deploy + Eclipse • Requires more management, documentation, co-ordination to ensure the same definitions exist in both orgs -> Trust! • Can easily get out of sync – reliance on documentation • Significant impact on timelines

Migrate to UAT/QA Siebel Salesforce • Copy srf across • Administrative setup may be exported, uploaded, or manually redone • Repository changes may be archived, exported, or manually redone; • Timelines usually quick • Migration process can be relied on • Cloud deploy, Eclipse platform • Both are not complete solutions. Combination is generally used, with manual re -configuration • In multi developer environment, huge risk of overwriting definitions – Manually redo! • Timelines longer for projects • Migration process uncertain requires extensive testing

Implementation to Production Siebel Salesforce • Test run gives accurate reflection of migration • Safety in knowing repository changes and compiled definitions have been safely migrated, intact • Rollback process quick and simple • Test run cannot be relied on Prod org handles migration differently from the sandboxes, eg. Code migration, test code failures • Timelines longer than expected • Major implementations require 1 or more days, depending on the extent of configuration; • Migration is not a well structured process, ie. No executable. Always run the risk of incomplete migration or overwriting definitions in Prod

Rollback, Backups, Version Control Siebel Salesforce • Rollback of db available • Rollback of srf/repository simple • Can incrementally determine source of bug by reviewing previous srfs/repositories/archives • Data may be requested to be backed up periodically – cost implication. Involves exporting data, and re-importing in need, rather than a DB backup • No concept of rollback for configuration • Changes implemented to prod cannot be backed out – will have to determine and manually remove • Cannot version control development reliably – used to reference rather than re-instate

General: Maintenance and Support of Software Siebel Salesforce • Regular quick fixes and patches released periodically • New release every 3 months • New functionality may be requested by the Salesforce community – Requests are voted on, and given enough votes, will be implemented in a future release

General: Certification Siebel Salesforce • Required to write full exam once • Thereafter write migration exam for each major release • Various levels – Administrator, Developer, Advanced Administrator. . . • Must write Administrator exam to qualify to write other exams • Required to write complete exam for each role once; thereafter release exams for each, every quarter • If you miss an exam, you lose your certification

SALIENT POINTS Siebel • High Cost Salesforce • Cheaper option Functionality • Numerous ways to meet • Can be quite frustrating requirements when requirements cannot be met because of limitations Ease of Use • Generally over-customized, • Very simple to use, however rendering it difficult and also simple IN use complicated to use

Siebel Standard Offering • 80% of industry specific functionality upfront • Inherent CRM capability Salesforce • Very generic in functional offering – one size fits all • CRM capability needs to be built • Offers a platform rather than a specialised solution Level of Skill • Resources need training and • Ranges from No substantial relevant skill set required, to resources needing training and skill set

Production Implementations Siebel Salesforce • Requires downtime on prod • Structured project approach • Longer timelines to delivery • No downtime required • On-The-Fly implementations • Structured project approach generally put aside – NB: risks involved!

SUMMARY Siebel • • Efficient Stable Reliable ‘Sky-Is-The-Limit’ approach ie. Must-Have Salesforce • • Convenient Economical Leading Edge Technology ‘Will-Make-Do’ approach ie. Nice-To-Have

My Humble Opinion: If you want SIMPLICITY, Salesforce is the way to go If you want FUNCTIONALITY, Siebel is the way to go