Nine steps to Siebel DIY support

Nine Steps to Siebel DIY Support


We already discussed about the reasons why many users complain about Siebel CRM applications in another article. In many Oracle Siebel projects a helping hand in understanding and solving application issues is very welcome. This often means relying on third-party support to provide guidance. But expert service comes at a cost: having someone supporting you 24/7 is not cheap and if the support is not handled the right way... you risk to lose control over your application for good!

 Here are 9 steps to guide you to Siebel DIY support

1. When relevant, start with analysing the Application UI - When we face Siebel customization issues, the complaint often starts at a UI level. Since the introduction of Open UI, some quite nasty things can be done, often not following Siebel customization best practices. For this reason it's important to immediately identify at a Siebel components level which Javascript and CSS files are involved, even before using your browser Devtools to inspect the html source. This because Siebel is not just a website, but a Packaged application with a complex infrastructure that lays behind the GUI - so it goes far beyond the 3 layers of web development!


2. Understand the application design - Unless some crazy Open UI customization took place, the real causes usually lay in the underneath layers. The first step in exploring an issue should be therefore understanding the application structure and behaviour determined by the user triggered events. You should uncover the hidden application architecture and behaviour in order to understand what is being triggered by the end user. Having a visual representation can be useful for a better understanding of the cause, but also for sharing the situation and discussing issues and alternatives with your colleagues, building up a shared knowledge model. The visual analysis can be automated 


3. Continue the exploration - In many cases the real application issues have deep roots: going into more details can be helpful in finding the real cause of the probelmand defining a new and improved solution. Either make use of the further automated analysis or get into depths yourself, for example by checking all the User Properties of the applets and Business Components involved in order to understand if workflowsbusiness services or server side scripts come into the picture. You might find some surprises.  


4. Go till the data layer - Sometimes, above all when performance is at stake, you cannot stop your analysis at the business logic layer but you need to continue until the physical layer. What you need to do is identifying all the tables loaded in a Siebel view and all the interconnections - maybe there is nothing wrong with the development, but a new index could be actually required to support a specific user key and improve loading times.  


5. Compare as-is development vs requirement - Application issues and complaint from business users are not always related to design or development mistakes. Sometimes errors happened in the erliear phases of the implementation. In this case not even the best third-party support team will be able to help you. What you need to understand is if the current implementation is in line with what was initially requested. Did the business sign-off on the automation? Is all that has been implemented necessary for the achievement of the functional process? A gap between requirement and development can determine unexpected application behaviours.   


6. Compare as-is development vs design - As you review the requirements that originated the designed, you shuould then check if the actual implementation respects the latest signed-off design. Maybe there is a discrepancy between the solution designed and the implementation. Gaps between design and implementation can cause different results: the design might take into account other requirements and existing features, thus needs to be correctly implemented. 


7. Identify cause & propose new solution design - Once the root cause is found, use the visual model you created to evaluate alternative solutions. Are there any technical or functional impacts from the new solution? Are there associated risks? Is it in line with the requirement without affecting the existing functional processes? Look at the new solution from all the possible angles before delivering it into production.


8. Document - documenting functional and technical implementation is paramount - it contributes to the team's knowledge and, in time, creates an internal reference library with issues, solutions and designs. Having a good documentation also means that when you find the same bug or a similar issues, you reference the work already done, solving it quicker and better. What is the down-size? Creating (good) documentation takes time. Why not use automated documentation tools and speed up your work? 


9. Go Visual - If it was not clear yet! By automating your Siebel application analysis, design and documentation via interactive visual diagrams you can enhance inter-teams communication and speed up every implementation phase by up to 60%.Following best practices and processes is always a good way to achieve a succesfull Siebel implementation but, without the right tool that supports each presented step, the process risks to become very hard and tedious to follow.

Software is born to facilitate tedious and complex human tasks, yet Oracle Siebel implementation projects are still too dependent on the quality of the consultants employed in the project. While e-Tools supports every phase of an implementation, the number of resources can be adjusted to focus on quality rather than quantity of repetitive, costly tasks.

With the recent publication of Oracle Siebel IP2016, new features will bring further Software automation power in the hands of the customers. e-Up is committed to collaborate with Oracle to make Siebel implementation projects easier and ultimately more succesfull with a fraction of the cost.

Stay tuned for the news on the new e-Tools features for IP2016.

DMC Firewall is developed by Dean Marshall Consultancy Ltd