Expectations and Changes

When doing a Siebel project, there will always be a balancing act between managing client expectations and delivering everything the customer wants. I am not even trying to finesse when I say managing client expectations. The way I put it in that sentence, you may have inferred I meant not delivering what the customer wants. But that is not really the case, as frequently, the client does not necessarily know what they want, or their understanding of what they want evolves as they understand the capabilities and the implications of a CRM strategy/product.

We see this unfold in different ways on different projects. In a green field implementation (new to Siebel), Phase I is typically a data model implementation where the majority of the development work revolves around building views. Now there is obviously a lot that goes on behind the scenes, but from a Client's point of view, we are mostly showing them views, and using a view as a way to communicate the concepts of a data model. That is, the view becomes the way to communicate relationships and attributes. The presence or absence of a field on a view becomes a visual indicator of whether a logical attribute exists or not in our build out. An attribute expressed as a single value field in an applet provides a visual cue that a user can only enter one value. Because the views provide extensive visual reinforcement, it is easy for stakeholders to identify gaps through the testing and acceptance process by saying, ahah, I do not see this field, or I need to enter more than one of that value, or their needs to be a view linking these two objects.

Integration based projects tend not to have the same issues when integrating to a legacy system as there are typically a pair of technical architect types that are fairly knowledgeable about the preexisting data models of each application. The project is mainly a matter of synchronizing these efforts. Testing and user acceptance though can again identify visually when a field or record set is blank to recognize that a gap exists.

Where I am leading to with all this is the nature of an automation oriented project. Automation is by it's nature typically new. Perhaps the steps have existed, but the mechanisms we are using to automate, to add speed to the process, have never existed before. This adds some expectation management issues that are a bit different than in other types of projects. The types of changes necessary have an added dimension. Gaps in the specifications will likely be caught dring the testing phase, such as a field not being populated or a decision branch executing on the wrong condition. The added dimension is time and frequency. For instance, a popular way to automate processes is to add reminders to a process when steps are not executed, or to change a status of a record to indicate an escalation in priority or status. I would posit that users do not really know how frequently they will want to be reminded because they do not necessarily have a sense of the scale or frequency of the events. Frequently, during an interdepartmental process, one department may perceive the severity of an issue as higher that the department they are working with. These are important considerations because a user that is reminded too frequently (when in fact they are aware of a task but are waiting on other deliverables in the normal course of performing it) will begin to ignore the reminders. Being informed of a number of outstanding items on a too frequent basis will cause us to phase it out as anything that can be happening so frequently is typically thought to be not too severe.

It is likely that system users will request, some time soon after deployment, that these reminders be scaled back, and if the capability to do so has not been built into the project, to turn them off altogether. This thereby loses the value of that particular automation. So, where am I going with all this? While workflows can be redeployed without a major release, it is unlikely most Siebel project teams are actually prepared to do so on short notice. It is possible to account for this by explicitly adding requirements for it, but of course this adds complexity and scope to the project.

This is all why I built the RARE Engine to be extensively customizable in the GUI, including the turning on and off of email reminders, the setting of the text of the reminder/escalation message, and the delay interval between reminders and escalations both on a per person and per process basis. This means that after the process has been automated and deployed, an administrator can tweak these parameters to the individual needs of the user base.

Economies of Scale - Data Edition

In the process of describing how a typical siebel installation reaches maturity, I summarized it thus:

...for any client, the first release or three are about implementing a robust data model, rolling on as many business units as possible to take advantage of the enterprise nature of that data model and gaining economies of scale, and maybe implementing some integration to get legacy data into Siebel

It strikes me that embedded in that sentence is another big picture concept I want to go into further detail about. Putting a call center on Siebel is nice for the Call Center and the managers of that call center from an operational standpoint. Putting a Sales division on Siebel is nice for those sales people and their managers too. In both cases, whenever a customer calls, the business case of using Siebel as a data model applies when we find that this customer has called before and we leverage that information to assist us on the current call.

Perhaps it is obvious, but it is even better when multiple business units are on Siebel, such that any given business unit can leverage the touchpoint history of the other business units when transacting with a customer who has corresponded with both. In other words, if a customer calls the Call Center, and the operator records information about that call, the Sales person can also leverage that same information, and the marketing division can market to that customer from the same database. This is what we mean when we talk about the enterprise nature of the application. The underlying data is to some extent shared with whatever visibility rules are deemed appropriate.

This is useful in the following ways:
More likely to get a hit when looking up a master data record.
Reduces the need to key in master data information that has been entered before
Increases the speed at which the user can transact the true nature of the call
Reassures the customer that they are known by the business
Allows user (or analyst or system) to identify a trend in the customer's transactions

There will often be a tension between choosing the best application to perform a certain task and gaining the economies of data scale identified above. This tension can be mitigated somewhat through good integration but it is unlikely to go away completely. That is, SAP may be a better inventory management application, so there is a tension between storing my inventory information in SAP which has built in and customizable algorithms, and storing it in Siebel, which while not as robust, has the advantage of making that data available in Siebel views and linking it to Siebel objects easily. Like I said, we can integrate SAP to Siebel, but this adds cost and complexity (and probably lag time). That does not mean it is not the right decision. In the case of inventory management, depending on how important that functionality is to the customer's core business, it may very well be the right decision. I just want to point out the tension between these concepts.

Activity Plans vs SMART Templates

I wrote a post recently about a new service offering I have been working on to greatly speed up process automation. So this is another entry into my teaser series. Let me start by describing what is probably Siebel's first and most basic attempt of process automation: the Activity Plan. Activity Plans have been around in Siebel going back a long time. I remember them in 2000 and they may have been there in 99.5 though to be honest I don't recall exactly when they made their appearance. Basically, an administrator creates an Activity Template consisting of a series of Activities. A user can then either automatically trigger the creation of an instance of this template (an Activity Plan) from an Opportunity Sales Stage transition or manually add one to any other object. Once the Plan is added, the Activities are automatically generated. This sounds great to a lot of business stakeholders as it sounds like something they can apply in many scenarios. It's strengths are:

• Can set any/all fields on an activity
• Creates many activities at once, saving manual effort.

Unfortuneately, once you start gathering any sort of requirements for a business process, you will start to stumble across the weaknesses:

• Fields can only be set to constant values (this really impacts dates when it comes to activities)
• Activities are created all at once, so any type of sequencing is impossible
• This functionality only exists for Activities (No Service Requests, or other custom objects)

Now with customization, there are ways to get around some of these limitations, but at some point, you will probably end up either building something completely different or bastardizing the Activity BC itself.

In my last post on this topic I introduced you to the RARE Engine (Rule-based Approvals Routing and Escalations). This is really two parts. I already touched on its features. There is actually a second component of my automation suite which I have branded SMART Templates. What a SMART Template does is to create a task record and set fields on that record, while addressing all of the deficiencies of the Activity Plan:

• Can create/update records of any type (administrator specifies the BC)
• Can evaluate fairly complex expressions including date math to set fields

And when used in combination with the RARE Engine:

• Records can be created in batches at different points in time, dependent on the completion of prior tasks.

OK, now we are getting somewhere. So once this service offering is implemented, any process can be maintained through the Siebel UI. You need to change the threshold at which a VP needs to approve an Order? No problem. You need to notify an additional person at a point in the New Customer Onboarding process? Ok. Or you need to create three new Service Requests when Final Contract approval is given? You got it. You want to update the quote status when the customer approves it through your eSales portal? You betcha. All these things can be done by an administrator in Real Time.

Just remember, most processes are just a series of steps executed by people or systems. What the RARE/SMART Suite provides is a way to implement automation quickly, maintain those steps in the Siebel GUI, and enrich the processes themselves (Reporting, Reliability, Refinement).

A Process Automation offering

I have discussed before that I think business process automation is the ultimate end state of a CRM Architect. What I mean by that, is that the ultimate way CRM pays off and that we as solution architects make value for our clients is to make real business processes that occur in our client organizations, and design mechanisms for the client to perform them in the CRM solution such that they execute faster, with more reliability, and to be measurable. In this case, the CRM solution is Siebel.

So my own work/life balance finds me pursuing three parallel threads on the work side (We won't get too much into the life side in this blog). First are my client responsibilities. I think all my readers have similar ones, so I won't go into them. Second, is this blog. My goal for this blog has always been a technical repository. That is, the solutions I post about here are geared towards technical Siebel professionals and can be leveraged against any functional design. My thoughts on why an open source approach for this basically comes down to the fact that any technical expert who sees this logic can and will take it for themselves. I mean that in the best way possible. What makes a technical expert truly valuable, is not only to understand new concepts, but to have a repository of all the things they have seen and done before. While, I think applying the algorithms I post about can return tremendous value to a client, I do not think these types of algorithms can be proprietary in the sense of the profitable. You would spend your life fending off those who copy and modify. I think the value to ourselves comes from showing our clients that we can understand these concepts and apply them. For me, writing a blog about them is a way to demonstrate that and I encourage other long term Siebel experts to do the same.

The third aspect of my professional pursuits I have not posted about before, but it is related directly to what I believe should be all of our prime objective when it comes to CRM, process automation. Basically, I have built another alternative to Siebel Workflow/Smartscripts/Task UI which has a different set of strengths for what I feel was missing in the Siebel base product. It is a task automation engine. The idea is that business processes are typically a series of steps or tasks assigned to different people. So I built a framework in which an administrator can setup and maintain these tasks and who they are assigned to in Siebel. The seed of my idea came from the out of the box Siebel Approvals functionality, and the Universal Inbox. Vanilla approvals can assign inbox items to a series of named employees or positions, and it is implemented in the Campaigns and Quotes modules off the top of my head. The approval thread can be either linear or parallel. This is interesting but it is immediately apparent that it is very limited. After all, a well implemented client may have spent a lot of time implementing complex assignment rules to assign objects to people based on all sorts of rules. I may want to assign approvals to people dynamically based on these same assignments. Or perhaps I want to approve dynamically up a position hierarchy. Or maybe what I need to automate is not technically an approval at all, but a series of service requests. Or maybe I want to assign an item to a different person based on attributes of the item being evaluated, say a dollar amount field.

What I have built hopes to address all of these functional requirements and much more into a product offering that can be administered 100% from the GUI and specifically adds value by addressing the three pillars of process automation:

1. faster execution - Escalation of items after designated time periods, scheduled reminders, Just in time notification to avoid "notification overload"
2. with more reliability - System controls the next assignee, rule based, version controlled rule matrices
3. and to be measurable - see current process status, steps stored in DB, can report on overall process metrics (avg length, bottlenecks, etc)

Getting back to my earlier point about what should be open source and what not. I have decided that this engine, which includes many functional algorithms will remain proprietary. I think the approach I have come up with involves some innovations which are not easily reproducible. I hope to use this blog as one mechanism to communicate my expertise in the area of process automation. I appreciate any good will and contacts I receive through this blog so feel free to let me know if something like this may be of value to your clients/employers. I will continue to post information about this engine in Teaser format.

The Big Picture - Let the Customer Do the Work

This is another entry in what I hope to be a series of Big Picture posts that are more about CRM technology strategy than step by step config or code snippets. My last post kicket it off, discussing how automation is where the value is. I stand by that statement but I should atleast add one very important addendum. I drew a picture of a CRM implementation as starting a huge data model in which your client can begin collecting lots of detailed information about customers and their transactions. Transactions involve not just their leads and orders, but also the service requests, activities, and other custom task records which together create a profile of a customer's interactions with the client. Automation generally targets the transaction side of that data model. For instance, when a customer calls in to report a problem, an automation project could result in a series of service requests automatically generated and assigned to the right people at the right time with the right attributes set describing work that needs to be done to address that problem.


Another great way to "automate" though is to actually eliminate the layers between the customer and the data representing them. In other words, let customers manage their own data wherever possible. This makes the most sense in updating profile information like name and address corrections, but it can get far more complex depending on the nature of the client's business. The tools to implent this can housed within Siebel through eService, etc, or external (a third party or custom built portal application that integrates to Siebel). Either way, customer updates directly updates master data in the Siebel database (or wherever the customer master is stored).


I have been at clients that are afraid of this paradigm, afraid that user's will enter garbage data, but mainly afraid of losing control. While it makes some sense to build a light validation framework around these interfaces, the goal of the framework should be to make things easier for the customer, not to lock down data. At the end of the day, the customer owns their relationship with the client and it is not in their interest to purposefully corrupt this data. Plus anyone interested in doing so can just as easily do so over the phone. Allowing customer's to directly update as much of their profile as your client's business allows should reduce the service request volume handled by the client's support staff. At a minimum, the creation of service requests through the internet can smooth out call center operations reducing peak call times by rerouting some of those calls to the web, and reducing downtime by providing emails to respond to in the interim between call peaks.


This concept applies to Sales as well as Service organizations. The ability to actually complete orders over the internet though will be largely constrained by the complexity of the product being sold. Clients will have to weigh the incremental value of making some additional sales over the internet (a universe of prospective customers vs just those the in house sales staff can explicitly reach) vs the potentially reduced margins of a simplified product offering capable of being sold in this way.

The Big Picture - Automation

I said in my opening post that this blog would be mostly technical in nature but I also want to wax eloquently on some best practice issues and some general CRM technology strategy. So let me start by talking about a proposition a friend of mine in the industry presented to me several years back. What he said was basically this (paraphrasing): "Siebel is damn expensive. Most clients spend millions on all the license fees and support costs, and never use more than the underlying data model. So instead of wasting all that money, let me put together a team of developers to install an open source CRM product to customize a data model for you on the cheap." The revenue model for him was in hosting that solution but you could make some money off the customization too.

I find this to be a pretty compelling argument because, in general, he is right. Most Siebel customers I have seen basically do use Siebel as a data model. What I mean by that they have deployed various numbers of views (depending on how widespread their user base is) with essentially the functionality to capture all sorts of data in elaborate ways. Now when Siebel first came out, that in and of itself was a pretty powerful tool. Both from the end user's standpoint who could use it to improve their customer interactions by first reviewing their history, but also from a management reporting (trends and forecasts) point of view. But let's face it. Lots of applications can do that now. I mean the basic idea of a table representing an account, a contact, an opportunity, and a bunch of transaction data with some views sitting on top of them is not exactly revolutionary anymore. So buying Siebel and using it in this way is not exactly going to return a lot of value. And the incremental bells and whistles that have been added along the way in the forms of various interface platforms are nice but do not really separate Siebel from the pack.

Well I am still working with Siebel many years later and I don't think it is enjoyable to work with a product you don't believe in so I must have resolved this value proposition. The key is really to drive process automation. Most initial implementations will probably still consist of implementing and customizing a data model, maybe some interfaces to fill that model with data from internal and external sources. But the important thing for clients to do, and for good system integrators to do is to sell their sponsors on the value behind process automation. This does a couple of things.

1. Increases the return on the investment
2. Reduces the opportunity cost of not investing in a simpler alternative.
3. Delivers a tangible benefit to the day to day end user which improves user adoption.

The first two things are two different sides of the same coin. By automating a process, you are increasing the client's bottom line in a number of potential ways:

• Reducing the number of steps a user is executing, thereby either freeing up user time to do other things, reducing the need to hire additional users, or allowing for maintaining constant operations with fewer users (yeah that is just a really complicated way of saying laying people off)
• Decreasing the time it takes to do things. This can lead to earlier sales, earlier conversions, and reduced downtime; all equating to higher revenues.

As for improving user adoption; how does it do this? Keep in mind when deploying a data model type implementation, the day to day user may end up actually doing more perceived work. In other words, in order to actually capture all those robust attributes about every customer, every deal, contact, order, etc, that data has to be entered by an end user. The presense of this data in a single system may save that user time in the long run

• Not having to enter it multiple times themselves
• Sharing the data with other users so as not to enter it
• Incentive compensated users will hopefully see a better conversion rate as they use the information better

But let's face it, many day to day end users are not the savvyest user groups, and see a Siebel implementation as more work for them to do. This is largely perception but that is the hand we have been dealt. Automation is a way to counter this. First, it is usually quite visible. User's see the records that have been created "behind the scenes" and know that the system did that job for them (obviously there is a sales job here for us to make sure users know this). This has a certain "oohs and aahs" factor to it. Second, more specifically, it directly reduces the amount of data entry an end user actually has to do.

So a good Siebel implemenation strategic lifecycle will first vastly increase the amount of data captured about the CRM universe, and then automate the way that data is captured and used. This should be a fairly iterative process so that end users are never overwhelmed by it. Siebel provides a whole tool kit of platforms to deliver this automation:

• Assignment Manager
• Data Validation Manager/Haley's Engine
• Custom Workflow Processes
• Task UI
• Smart Scripts
• Analytics (outside of Marketing, this can be a trigger to start process to upsell or solve problems before they happen)

And not to sell this community short, it takes a really good integrator to get the job done right. Knowing how to use one of the above tools from a technical standpoint does practically nothing if they are not implemented in a way that makes strategic sense for the client. I have done a lot with Assignement Manager, Workflow, and DVM so I may touch on those in future posts.

How to call Workflow - Custom

An alternative to the "Managed" runtime events, meaning that the process of activating workflow process creates and updates runtime events and action sets, is to create your own runtime events and action sets. This allows you to create complex sequences of workflow process calls, perhaps setting several profile attributes that are needed in the workflow, calling different versions a workflow process based on mutually exclusive conditional expressions, and calling workflow in different calling modes. With great power comes great responsibility. Walking away from the simple management the activation process provides gives you a lot of flexibility but it also makes your system more complicated and deployment a bit trickier. I think I have said deployment is trick either way now, which when you are talking about complicated processes is probably true regardless. I tend to think the custom route is easier to understand because you control all the steps and the names are more logical because they are your names.

So let me start by defining what I mean by custom managed events. You can achieve the same affect as the managed architecture by creating your own runtime event in the GUI (Administration - Runtime Events) with the same parameters used in the tools workflow pallet, start branch step attributes.

Then you create a custom Action Set with as many custom Actions as necessary. Conditional expressions can be used to prevent the instantiation of a workflow process manager component unnecessarily.The step that needs to actually calls the workflow will have an Action Type of 'BusService'. The Business Service Name will depend on what mode you want the workflow to run in. To simply replicate what the managed process does, just set the Business Process Name to 'Workflow Process Manager', the Method to 'RunProcess', and the Context to "ProcessName", "workflow name" where workflow name is. . . you know. This is a Name, Value pair format for properties accepted by the business service.
It is important to recognize that dynamic process properties cannot be passed to the WF through the business service context. This is because process properties are expected as a child property set. Plus the business service context cannot resolve expressions. If you need to pass dynamic process properties to the workflow, you have two options. You can either set a profile attribute that can be referenced in the workflow or you can create a shell service which I will get into in my next post.

How to call Workflow - Managed

Workflow can be called a variety of ways, with a variety of advantages for each. This will be the first post in a series about the pros and cons of these various mechanisms, along with a tool to assist with some of these approaches.

The most basic, declarative, out of the box way to call workflow is through a run time event managed by the start step of the Workflow process. Let’s take a basic workflow that is meant to call a custom business service when the Account is updated. If you select the branch from the start step, the WF Step Branch applet appears beneath the pallet.

The Event attributes specify a Runtime Event and Action Set that will be created in the GUI when the workflow is deployed and activated. The Action Set has the naming convention Workflow_Row_ID where Row_ID is that of the Action Set record. The Action Set has a single action whose name is Workflow_Row_ID_Row_ID where the first Row_ID is that of the deployed workflow process (can be found in the Active Workflow Processes applet of the Workflow Deployment view). I am not really sure what the second is.

A workflow process called in this way is considered to be running in Local Synchronous mode. The Local refers to the fact that is executing from the same thread that is was called from. So if a user action in the GUI triggers the run time event, then the workflow would be executed within the Sales Object Manager component (or whichever); if the an EAI update were to trigger the runtime event, the workflow would be executed in the EAI Object Manager. Therefore turning up event logging to troubleshoot a workflow called in this manner would require doing so to the Object Manager. The Synchronous part refers to the fact the user session will wait until the workflow has completed execution before control is returned to the user.

If instead of a business service, you had Siebel operation steps in the workflow, it is important to realize that any queries executed would take the most restrictive visibility of the object being queried. In the workflow above which is based on an update to the Account BC, adding a Siebel Operation Query on the Account BC would automatically apply Sales Team visibility to the query. Where this sometimes has an impact is if Assignment Manager runs synchronously between the time the triggering record is committed and when the workflow executes. In that case, the account may no longer be visible to the person who updated the record.

Some of the complexities in managing workflow this way are when you need to do a series of things in a particular order. Finding Workflow with this naming convention can be confusing, but in theory, knowing the naming convention means you can identify the action set you need, and you could then add your own custom actions to that action set, say to set some profile attributes prior to calling the workflow. Or you can add a conditional expression to the action. The hard part is when you need to deploy a new version of that workflow. The deployment and activation process which manages the naming convention can corrupt your custom actions, requiring you to set them up all over again. Deployment in general can get tricky with this approach because the Row Ids are used in the names and Row Ids between environments will differ for the same process. This means that you need to deploy and activate workflows in each environment to generate the runtime events and action sets, but if you need to migrate runtime events and action sets for other reasons, either for personalization or other custom development, you will need to be careful that your workflow managed runtime events from your source environment to not migrate and hence become duplicated in the target environment.

UPDATE: I recalled another serious limitation of this approach.  Workflow called in Local Synchronous mode will only execute if the active business object at the time the runtime event is triggered matches the business object of the workflow.  This implies that if you have a runtime event on the write of an Activity, you would need multiple workflows, one for each business object the Action BC appears in that needs to trigger the workflow.  If you have determined this is still the best approach to use, I suggest a series of shell workflow processes that call a single primary workflow as a subprocess where the primary is based on the main Activity BO, and the shells are based on the various other BOs, all having a single step.

Migrating Meta Data - The Release field

Something I have now implemented on a couple of clients and I find quite useful is an enhancement to ADM (Application Deplyment Manager) to group meta data items together for the purpose of a release. Out of the box, ADM has data types for migrating LOVs, Views, Assignment Rules, etc from a source environment to a target environment. The mechanism provides for a search specification to determine which records of that data type should be migrated. This search specification can get quite complicated over time though.

What I propose is to extend the base record of each meta data object with a new column signifying the release. Simply add the column X_RELEASE to the parent table (S_ASGN_GRP for Assignment Rules for instance). Expose this column in the business component the table is based on, and in the applet the BC is based on. I recommend a varchar data type which will provide a little flexibility in how you version your releases. Finally, modify the ADM integration object. These are the ones prefixed with 'UDA'. You will need to add the same Release field (corresponding to the BC field name) to the Integration Component corresponding to the BC the field was added to.

Now, in the GUI you can mark all the record of that meta data object with the release description, such as '1.0'. In the Deployment Filter of the Deployment Project/Session, you can then specify, [Release] = '1.0'.