Monday, 9 March 2015

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.
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

No comments:

Post a Comment