Funky Town

A lot of articles on Impossible Siebel are an exploration of what is possible than what is normally recommended, it is hoped that readers would take these ideas, concepts and techniques (added with some common sense) to solve tricky requirements, within the guidelines of each project.

But what are the consequences when we say no to unconventional business requirements?

[Experience 1]

Recently i walked into a local communications store, to buy a new cell phone. The clerk was training a new starter on how to use the system, and i noticed that they had Siebel eChannel on their monitor, which started grab my interest.

The clerk explained to his apprentice, that they needed to check to see if i am an existing customer, otherwise they will need to create a new account for me.

Because i didn't know whether i had an account with this company or not, they had to first search for my details in their system. This is when the clerk told his apprentice, to switch away from Siebel to this other web based application to perform this search and create my account. The clerk explained to his apprentice that, this other system was easier to use.

Siebel: 0
Web based system: 1

[Experience 2]

I had a similiar experience at my local bank, when i met with my banker. I knew the first thing that he was supposed to do, when we sat down was open up his Siebel application, and start a "needs conversation" with me.

A "needs conversation", is process where the banker should go through an interview type transaction, ask me a series of questions relating to my current circumstances, and put this data into Siebel. At the end of the process Siebel would come up with a list of recommended products to offer me.

I knew this, because i knew the team that delivered this functionality. Instead the banker used a java portal to look up my details and get a summary of my data. He wrote everything about our conversation on a piece of paper and made up some recommendations from his head. Interestingly I also knew the other team that developed the java portal, and the UI was so intuitive, that i didn't blame the banker.

Siebel : 0
Web based system: 2
Paper based system: 1

[Experience 3]

I walked into a rival bank, and told them i wanted to open a business account. As i sat down with this employee, he used his CRM system to record my conversation, i was quite alert to this, and i asked him to show me his application. He was quite proud to show it to me, because it was a very nice .NET application that was fluid, responsive, the UI was very clean and minimalistic. It was also very sexy, and you can tell the UI was built by a well paid designer, not just some guy in the team that does web design as a hobby.

Siebel : 0
Web based system: 3
Paper based system: 1

[User Centric Design]

Custom applications have the advantage over Siebel in user friendlyness, because there are things that you could do with current web technologies that are never "possible" in Siebel,

Lazy loading UI
Async calls with callbacks
Fancy transition animation
Dynamic UIs
Inline field validations
Word completion


But lets not dwell on the negatives too much, because Siebel is a vast product with a lot of technologies that allows us to build a descent and usable interface. If you're lucky enough to work in an organisation that has a good User Centric Design (UCD) team, that hasnt been contaminated by limitations of Vanilla Siebel, get them involved during your solutioning and prototype stage.

Try to mould the application around UCD principals, and avoid designing form applets with 100 fields, with 10 different buttons scattered across the top. The problem is Developers arnt Designers and Designers are often told that Siebel is impossible.

[Go the extra mile]

There is an argument that, the user should learn to live with what the system has to offer, and with proper brainwashing...sorry, i meant training, the user will get to use to its limitations and accept it.

But there is another "school of thought" which says, if the technology is out there, and its supportable, use it and give the client what they want, of course it has to be supported by good architecture, but go the extra mile and make life better for the user, because you don't want the user switching to another application.

The question is, whether we should give the users what they want, knowing that what they ask for will have some future upgrade or maintainance effort, or throw bookshelf at them and say its not possible.

Remember the risks, if we dont give the user what they want, they will use another system or worse, use a piece of paper instead.

Imagine, that a few years down the track, business decides to build a new web 2.0 portal to interface with Siebel as a back end, because it dosnt meet certain usability or accessebility needs. Look further down the track, this sexy portal takes over, and Siebel becomes a legacy system that is too costly to maintain, it is de-comissioned and replaced with newer technology.

Lets take a one last look at the scores again.
Siebel : 0
Web based system: 3
Paper based system: 1

So next time, the business asks you to perform some unconventional configuration, ask yourself these questions

1. Will it perform well?
2. Is it maintainable?
3. Can it be upgraded?


4. Is it sexy?

This is the beginning of a series of articles, where i'll introduce a funky requirement, and you guys tell me, if you would go the extra mile to implement it, and along the way we'll tackle some of the impossible limitations above.