CRM and Cloud Computing

For the past few months now, I have been following developments in the cloud and those are all cheery and bright. CRM being one of the not-strictly-in-house applications, is one of the prime candidates for "clouding" and obviously those of us who depend on CRM for a living are going to look at the developments closely. I am of the opinion that for better or for worse, moving services to the cloud is where we are headed. Software as a Service (SaaS) has already proved its mettle and has not limited itself to SMBs. However for those of the companies who just want their application but not the hassles and for those who may want independence to scale hardware and infrastructure as they wish, moving services to the cloud is an option. And that option has been picking up lot of heat with Amazon & its cloud services, Microsoft & Azure and so on & so forth.

With the above as backdrop what I really wanted to discuss is the recent McKinsey report, which has been interpreted at many a place as "cloud services are ineffective". In many ways, I see this hype/anti-hype as similar to that generated when initial SaaS discussions were on. SaaS came and is here to stay. But that did not make the current software market vanish (though I understand Mr. Benioff has been trying to do just that). Though the dust is not all settled today, we still see a lot of software vendors out there who are making a profit (with a decline on the cards) and at the same time there is a aggresive growth in SaaS market. With the ever lessening costs of SaaS, ever increasing competition and the ease & sophistication of customization options, we might see organizations moving to SaaS over a period of time - nothing overnight. Who knows SaaS vendors may unveil even better strategies to capture new segments by addressing many of the critical issues that face the customer today - yes, including data security concerns.

I see a similar analogy in the cloud services market that will include more than just the one-fits-all software. No data centers are going to move to cloud over night, but will be a gradual process. From where I stand, it makes business sense for the provider to put together a bunch of options and let the users use remote servers and services without the hassle of maintaining one. This has to be cost effective and can result in better resource utilization in the long run. But, not all organizations will be able to do it - may it be geographic constraints or plain "sense of ownership" thought-process. The McKinsey report does deal with such questions and the observations are simple:

• Cloud reduces upfront costs
• Almost immediate access to servers
• Smooth scaling up of services on demand

Cloud services already has made a dent and does make a lot of sense for the SMBs but large organizations would be better off by not investing too much too quickly. Hosting your services in-house costs lot cheaper than putting them on Amazon. New technologies tend to garner lot of interest and that sometimes over-cooks it - too much hype will not automatically translate into benefits. I for one sincerely believe cloud computing will be mainstream and will define the standard in not-too-distant future. Ultimately what will work is the same mantra as IT outsourcing - "We want to concentrate on what we do best and let the IT part be handled by specialists". Here we will have organizations who want to be agile in their response to market and leave the infrastructure & software to be maintained elsewhere. What do you think?

Back for good

I am back after a long time, had to attend to some serious issues that would have taken away my source of income. And this is not what you want to do in these times of recession.

I have seen a couple of more projects hence and still wonder what makes project teams tick? There are a few people around who actually like what they do for living. Day by day, project by project you see the same mistakes repeated often. The same review comments given out by Oracle and the flurry of fixes. Unless you have a tight grip on ALL configuration objects or have someone interested do it, you are pretty sure to go through the 25 pager that Oracle ES doles out for minor defects in 25 objects!

Anyway, here are a few must-do's in all Siebel projects:

1. Keep Configuration and Scripting best practices handy. Get the team to go through it at least twice and once more to make sure everyone knows the game
2. Quality is everyone's responsibility. Maintain strict traceability on customization and hold team members responsible for deviations. No, I do not mean to thrash them but make them correct mistakes. Pouring over the same code again is punishment enough
3. Appoint a elite review team consisting of 20% of team members. All "critical" development decisions (do we need a separate view or shall I use applet personalization in the same view?) have to pass through these guys. Also, make them directly responsible for all objects/code reviewed
4. Organize fun events every month or so during the development period and announce prizes for people who identify deviations from established standards
5. If your organization has internally developed a configuration review tool, use it frequently during development. If you have no such tool, it is good time to consider developing one

Ofcourse this is not a comprehensive framework, but something I have implemented in a few projects and regret not implementing them in a lot of projects. Do they indeed make sense? What other ways do you follow to sustain quality deliverables? Please comment!

Tackle Siebel Performance Problems

As you read this, try to recall how many times has this happened to you. The development team has slogged for more than a few days to produce a piece of art and deploy it in dev environment. Everyone's happy and within no time it is promoted to QA. If you have a “proper” QA, there is a big chance that someone starts complaining about performance of the new/existing view. First, you try denial and try to concentrate on more immediate issues at hand, but finally comes a day when you scramble to put together resources to resolve the problem.


I have been in more than a few projects and believe me when I say this – most project teams end up in the above situation, unless they have put in a process to tackle performance problems as part of their development process. And what do you know, the biggest surprise is not many teams do that. I believe the development team becomes so engrossed in their day-to-day work, no one really finds time to do anything except create, modify, fix and forget cycle. The real bad thing here is that performance problems have a cascading effect – they inflict major damage to user community in terms of positive mind share and that damage is not easily reversible. So, it's good to start early. Let us try to outline what can be done.


>> Control UI

A client I worked with had his users believe that a list applet can only contain 20 fields. Too many fields being pulled from too many sources may be good to look at, but are they really doing anything there? Could you accomplish the same using reports (preferably OLAP!), could you convince the user that an extra click can retrieve the data but that click is going to save him 2 seconds to view most wanted data?


>> Best practices are your best friends

Never under estimate best practice just because everyone echoes the same things. Never allow non-indexed searches, control searches using home page / find dialog / custom query applets, never have MVFs without primaries, index all foreign keys, do not script for something that can be accomplished in an alternate way, but at the same time do not be afraid of scripts when they can save a bunch of queries using Siebel operation steps in a workflow.


>> Use light BC

Some of the OOB classes are heavy and come with a cost. For example, order line item updates may fire numerous queries for repricing the order. The cost is decreased by a large magnitude just by using a clone BC based on CSSBusComp class and doing a reprice after all updates. It may be interesting to note that there are several cloned business components already available OOB in v7.7+, take a look around


>> Async it!

Evaluate whether your user may proceed with his work while you accomplish work in the background. For example, clicking on Submit button changes the order status and returns control to user, while working away in the background.


>> Don't cut slack with your review process

Examine and evaluate every join, every new field exposed newly on applet, every field that needs force-active or link-specification to be TRUE. Balance these factors against the performance trade-offs. For example, consider a one off query when you can afford it instead of just turning on Force-Active an d including the field in all queries


>> Put in a robust performance measuring mechanism

Measure performance before and after proposed changes. Do not talk in terms of time or number of seconds, always do comparison using consistent gets. These gets will tell you how much work the DB has to do for retrieving the data that more or less remains the same across environments and regardless of “how much” data is present or the load on DB servers.

What I miss from Siebel 6.0

I know that this title makes some people shudder. Siebel 6.0, they say, is only perfect as a historical showpiece. I beg to differ, at least till the time required to complete this post. Sure, I agree that Siebel 7 revolutionized things around here. If something is not browser based, I would not be taking any bets on the application mortality. Nevertheless, this should no way undermine the beauty of v6.0 application.

Release in the year 2000, v6.0 aka Siebel 2000, brought in more stability and looked better than the earlier versions. Also significant was the concept of “integrated channel management” – one application to manage your sales, marketing and customer service across channels incl. web, wireless and call center. A few features mentioned below makes one fondly remember of v6.0:

• First and foremost aspect - the architecture, client-server worked like a charm. No IE, no fuss, no security concerns and no worrying about the next security patch killing everything except the manager. No worrying about different components that are at the mercy of different machines and operating systems
  
• Performance – Any Siebel 6.0 developer would laugh off performance testing and happily do some more customization
  
• Less network bandwidth – Everyone used local mode most of the time and everything ran on the local machine anyway. Even when you are connected to server you only need to ferry the data between application and db
  
• Deployment bandwidth – Deploy with zero downtime – of the local application that is. Take your own sweet time to bring up the server and let the users synchronize over the following week
  
• Usability – Responsive, access all available views through the menu (who says Sitemap is the right way?), an intuitive search and lesser screen refreshes – try navigating to the next set of records in a list
  
• Looks – Apply windows theme and change the application looks, customize it to work on VGA or revert to the way v99 looked. Also, show or hide gridlines, alternate row background colours and customize your tool bar (through options set at the individual level, not through Tools)
  
• Extendibility – You want anything not supported OOB? – just write some script, no worrying about server/browser scripting and the server-client round trips
  

Sure, there are not many points - v6.0 was no match for the "CEM" attitude of today. But for a time it did successfully held & expanded the forte of Siebel through the 'difficult' period for IT in the year 2000. All said, I have no love lost with the latest and greatest v8.0. After working on v6, albeit for a short time, I enjoyed the transition into the web & party model of 7 (& the accompanying hiccups - it generated lot of work :)), the robustness of 7.5, all the extras in 7.8 (still think it should have been the next BIG version of Siebel) and the user friendliness and wow-so-many-features that symbolises 8.0. And yes, all hail Fusion - I will be ready for it, whenever it comes!

Spying with Web 2.0!

As an IT consultant and business IT process evangeliser, do you think you have the toughest role in managing information? Do you think you have a big problem in your hands in getting your team to "talk to each other" and believe all your problems would just vanish if there is effective dessimation of information? If yes, you need to go through the ten pages of gruelling information sharing problems faced by the defence agencies in United States. Chances are you have been through it, but I recently stumbled on this article and wanted to share that in this space. With the dynamic and ever-changing face of today's terrorism, what one can do in terms of harnessing collective intelligence to put up an effective counter-strategy?

The story gives an interesting anacedotes on what was happening circa Sep-2001 and what is relevant now. Back from the days when the bosses digested information to analyse what is important and not, the focus has moved towards grass-roots analysis. Agents in multiple agencies write and comment about the situations, threats and intel. A series of tools - WIKI, Chat Rooms and Blogs provide the platform. The number of comments will enable them to connect the dots and do a comprehensive analysis of the developments. This is crowdsourcing in some serious action. An important takeaway - "Social tools will not succeed unless the people aren't social". Though it so stares you in the face for all Web 2.0 initiatives, the benefits derived from the system when it achieves critical mass is simply stupendous.

A good takeaway hidden somewhere there for all of us non-spies?

Customer Service Experience: Role of IT

How many of you know that ICICI offers you privileged banking if you maintain a "salary" account with them? I for one certainly didn't, and I am sure many of my friends share my experience. I came to know that I was a privileged "Gold" (or whatever) card customer when I lost the privileges since I changed my main account. 

I don't normally care about this or that privileges that companies say they offer to their customers. However, these ones are supposed to have prioritized servicing at all of their branches. If you are like me you will visit the branch once in a decade, may be, and it is then you actually find out the queuing system! The branch near me has this token servicing system based on FIFO and availability of manpower. If you are planning to visit the bank on the way to office, you are certainly getting pricked at personnel not in office even by 09:30 hrs (promised time: 08:00) and the seemingly hundreds having a token number lesser than you. Now you would love that silly privilege, wouldn't you?

My next question - even if you know such privileges existed, do you really believe things will work out smoothly? I invest in Indian stock markets and can take a safer bet that it probably would, after painstaking arguments and escalation to the manager. In due course, people just end up with the glossy card and nothing more.

Now, what is this content doing in this blog you ask? Well, Andrew McAfee's recent blog post (http://blog.hbs.edu/faculty/amcafee/index.php/faculty_amcafee_v3/why_some_business_innovations_cant_get_off_the_ground) got me thinking of similar instances in our day-to-day lives. This whole experience could have been much better if the IT system enforces the privilege rule or the token issuing system somehow is tuned to recognize the type of customer. Regardless of the employee mood, the privileges are always extended to the most valued customers. The bank successfully gets its message across.

One good example I have seen is my recent experience with Big Bazaar. I use Sodexho Meal Pass to buy groceries and those who have used it know how clumsy it is to handle and at the same time, trying to avoid the steely look of people in the same queue. More important perhaps, shops do not hand over cash change if you use those coupons. This particular day, I handed the counter sales-person coupons worth Rs. 1700 against the bill amount of 1698.25. Like all other good software the system did not like the Rs. 1.75 more. The person at the counter confirmed with me his inability to hand back change and entered a dummy card number to redirect the extra 1.75 to a Children's Fund. To top it, this counter guy was no old hand, had an id card of a trainee. Simplicity and effective enforcing of business rules, must-have elements of a great software. Specific to CRM, it enables organizations to reaffirm commitment to the customer is each transaction or at each touch point. If you are implementing CRM, you now know the importance of all those pesky business rules that you grudgingly customize.

Siebel: Sensitizing Case Insensitive Queries

There was a time in the not too distant past - whenever users ask for certain fields to be case insensitive, developers had an answer - "look it's not like we can't or won't do it - it is just that the performance takes a beating". Now things look a lot easier.

The Problem

Siebel applications are case sensitive by default. Although we would certainly like to see them as another Google search - enterprise search was never really a Siebel forte (hold, I did not come to Siebel 8.0 improvements and Oracle Secure Search!). Now, searching for accounts or contacts would require the users to have a general idea or adhere to a framework of naming convention. An "ABC Company" here and "Abc Company" there, albeit a typo, result in frustration for the users. If you can have your whole application case insensitive you just turn on a switch and you lead a peaceful life. But unfortunately, not many of us are blessed with small databases or user-base and the kind of queries that requires users to take coffee-breaks are not encouraged.

Tackling case-insensitive queries assumed monstrous proportions in some implementations. Users have to get their work done. So there were a few work-arounds:

• Force case sensitive queries for desired fields by prefixing the queries with "~". Might have user-training problems, users are not happy with the extra typing (you have to really search for the damn character). Again, this might lead to the coffee-break problem, although in a much smaller scale
• Force a single case (like all caps) for certain fields like account or contact names. Again, not a beautiful solution, requires lot of user discipline

Then, there were developers - they have to maintain a certain level of user-satisfaction in the interest of their jobs and so were more work-arounds:

• Tell users to use ~ in their queries. Create indexes (like functional indexes) to manage performance loads
• Make selected fields case insensitive and manage performance through indexes
• Force case on fields and enforce user discipline
  
• And another interesting solution, which is now mainstream - enabling case-insensitivity through a redirection approach (you have to go through the entire article)

How Siebel Helps?

Enter CIAI (Case Insensitive and Accent Insensitive) wizard in Siebel 8.0. In there, we have a more streamlined way of dealing with enabling case-insensitive queries for specific fields.

What you do, as a developer, is pretty straight-forward:

• Select columns of interest
• Invoke CIAI wizard
• Select all indexes that need tuning
• Let wizard do it's thing

What you do, as a user, is more simple:

• You use the enabled fields to query - no case, no nonsense
  

What CIAI wizard does is not so simple:

• Change default insensitivity property to "DB Case & Accent" for the specified columns
  
• Optionally, create child columns that are same as parent (or previoulsy specified) columns except for the force-case part. In the background, all values are stored in one case
• Optionally, delete index including parent columns and recreate indexes for the child columns
  

Now, the object manager reroutes the queries on specified columns to the case-insensitive columns that in-turn use the case-insensitive indexes to return results that are case-insensitive. I bet you don't want to hear the term case-insensitive again (there you go!).

We can run CIAI wizard multiple times and even turn off the changes made in prior executions. Note that there are a bunch of prerequisites. More important ones - only certain table types like Data (Public/Private/Intersection), Extension etc. are supported and only char, varchar and CLOB data types can be configured for CIAI queries.

Interested to learn more? - Head to "Configuring Siebel Business Applications" in Bookshelf.