Siebel Open UI – My Top 6 - What NOT to do!

Siebel Open UI – My Top 6 - What NOT to do!

1. Don’t approach the project as 2 separate projects - Siebel Configuration Work + OpenUI Web Development work

Most teams end up seeing an OpenUI implementation as 2 separate projects

1. The Siebel Side Changes – BC’s/ Views/ integrations etc.
2. The web changes - creating Presentation Model (PM), Physical Render (PR) , jQuery etc.

A Siebel OpenUI implementation is unique, as it doesn’t work in the same way as other Siebel projects involving multiple systems and teams where a certain degree of 'black box-ness' works. Whilst knowing HTML, JavaScript and CSS is handy, it isn’t the only skill or knowledge the 'web team' needs for a successful OpenUI implementation. Take a quick read of Alex Hansal’s Siebel Blog about this. http://bit.ly/1DN1Zs4

The Web team needs to get an understanding of the concept and architecture of the PM/ PR before their web skills can be used. A silo-based approach only leads to question like –

Who does the Siebel side of the work?

Who does the web part?

What is part of the 'Siebel side work'?

I thought the ‘other’ team was doing this!

2. Don’t “Convert” all 5000+ views to OpenUI

Siebel has 5000+ views available for you to “convert” to OpenUI. You need to figure which ones are 'useful'. A good start is to go with a 95:5 rule – I have evidence that 95% of the views in a person’s responsibility will never be used.

Ask yourself if you REALLY need to show that view across 4 browsers?

A little bit of usage analysis goes a long way in figuring out which are your bread-n-butter views. Start your OpenUI project with those views, don’t try to do everything, come up with a low impact deployment plan.

3. Don’t ignore that flawed process, its not going away unless you fix it.

Most likely you're looking at OpenUI because you already have Siebel. Are their processes that JUST DON’T work for your call centre users? Does it take too many clicks to get to the info they really need?

NEWS FLASH! OpenUI will NOT make that go away. You will have to sit down and put effort into defining these processes first and then figure out how to use OpenUI to create that perfect user workflow.

4. Don’t believe that OpenUI is a fix for an incorrectly configured or designed Siebel implementation.

Do you use scripts for all sorts of field and form validations? Could there be vanilla User Properties that could be used for those?

If your Siebel App is not designed and configured properly, just migrating to and installing OpenUI is not going to magically fix those configuration issues."

5. Don’t blame OpenUI for all performance issues with Siebel

"It takes forever to see the Quote Line Items on Chrome!'

'OpenUI is really slow!'

'It can't take that long to show me the pricing on an Order!'

Any or all of these sound familiar? Let me share a secret - Its NOT OpenUI! It’s your Siebel app! OpenUI will not fix the performance issues caused by bad application design or an un-tuned DB schema!

Upgrading to OpenUI is like adding extra gears to your bike. Sure it’s supposed to make it easier to use, but its not going to fix that flat tyre. You'll need to get that tyre replaced before you see the value of paying for some fancy new gears.

6. Don’t do stuff 'just because OpenUI now lets you do it'

Developers may be itching to add animated views and flashing text… but again… do you really need it? Your users will quickly grow tired of the novelty. So, just because OpenUI lets you do it doesn’t mean you HAVE to do it.

Are you on an OpenUI Project now ? Feel free to add your experiences below and help others in the same predicament !

Read more about our Open UI Services and Solutions on our Website - Siebel Open UI

David.moorman@crmantra.com

It’s Open Season on Open UI

It’s Open Season on Open UI

Siebel Open UI – Are you excited by the possibilities, but daunted by the challenges?

We can help.  CRMantra’s Open UI Assessment has increased the ROI from Open UI deployments for many Siebel customers. Here’s how.

·    Laser focus.  Why waste development time and resources on views no users visit. Siebel deployments use less than 5% of available views. CRMantra Open UI Assessment identifies which views your users visit.

·   Rolling Thunder.  Reduce the Open UI deployment risk through a phased roll out.  CRMantra Open UI Assessment will provide the breakdown of views visited by each subset of users.

·   Eyes Wide Open.  Know the technical issues and challenges before you start.  Open UI Assessment will analyze of your Siebel repository for technical issues and provide an estimate for resources required to address each technical issue.

Contact us to schedule your Open UI Assessment.    Results in weeks and at a fixed price.  Open UI Assessment does not require any software purchase or licensing followed by lengthy implementations. We stand behind the estimates to address the technical risks.  You will know upfront what it would cost to deploy Open UI if you use us!

The methodology for CRMantra’s Open UI Assessment has been validated and approved by Oracle – (See My Oracle Support - Doc 1626424.1).

Read more about our approach on our website Siebel Open UI

Or get in touch with me at
David.Moorman@crmantra.com

 

At the Horizon – Does Cloud meet OnPremise?

At the Horizon – Does Cloud meet OnPremise?

On one of my long flights, I had ample time to reflect on our experiences working with customers on the terra firma (the on-premise world of Siebel) and in the cloud (primarily, Salesforce.com).   I was struck by how similar these applications have become.    

We have had Salesforce.com as our internal CRM for over five years and I have always marveled on how easy it has been to implement.  Yes, it required no programming.  We were able to configure it within a couple of hours and our team was fully functional – no training necessary.  For Siebel specialists that we are, this was indeed too good to be true! 

Platform as a Service or On-premise in the Cloud

Simplicity and ease of implementation has been the engine behind Salesforce.com’s rapid adoption across many customers.  Salesforce has since released a lot of powerful features such as Apex programming, Visualforce, Salesforce1, the Force.com ecosystem, etc., to evolve from an SFA application to an enterprise-level front office platform in the cloud.  These features have enabled customers to write custom scripts, create custom objects, add custom fields, and design custom applications, workflows and processes – something commonplace in the on-premise world.  The flexibility offered by these features in on-premise applications is what got many of them into trouble.

Insights from the Field

Indeed we see customers with cloud-based CRM apps facing challenges similar to those seen in the on-premise world.

I was talking to the Director of Sales Processes of a customer regarding initiatives they have underway.  She mentioned “Reducing Sales Drag” as their main initiative for the year.  I asked her to elaborate upon what ‘sales drag” meant to them.  She listed user adoption, complex user interface, too many approvals, and non-standardized rules as issues they are trying to address.  My jaw dropped open.  These are things we normally hear from customers who have had on-premise apps such as Siebel. 

I was visiting with another client a few weeks ago.  Our discussions touched upon various topics, one of which was expanding the footprint of salesforce.com across their organization.  The Director of IT was concerned that a wider roll out of Salesforce would be a non-trivial task.  One of their divisions had already used 438 fields on the Customer object!  A wider roll out would hit up against the limit of 500 fields per object in Salesforce.

The Takeaways

In each of the above cases, after some further due diligence we uncovered the root causes for these problems. These are lessons many on-premise customers have learnt, albeit too late, and are equally applicable in the cloud world.

1.    Process Design: Because it is on the cloud doesn't mean that process design can be ignored.  Invest in designing the right processes before embarking on the implementation.

2.    Release Hygiene:  Just because it is easy to add a new field, implement an Apex script, and quickly release it to production, doesn't mean you should.  One needs to make sure the changes are in line with the process design that has been agreed upon for the application.

3.    Coding Discipline:  Cloud is no more about No Software.  Apex is the lingua franca across Salesforce.com.  One needs to follow the software development best practices in order to obviate performance and maintainability issues.

Read more about on our website  - Moving to the Cloud?

Twitter @CRMantra or facebook.com/crmantra or visit our website at www.CRMantra.com