October 2008, Implementation Project Discovery/Design Stage Requirement Solutions
By harvey.saks on Nov 18, 2008
In this month’s article instead of talking about past projects, I discuss a pet project that I have been working on. For quite a while I have been advocating an approach that I believe will reduce the time and cost associated with the requirements gathering and design stages of an implementation project.In the past, Siebel, and now Oracle, have provided features of the CRM product meant to reduce development and deployment costs, but only a few products have looked at helping to reduce the cost of a projects Design stage. In years past one of the contributing factors to project failure was associated to problems with Design and User Adoption issues. Siebel responded with a training class for Business Analysts and a methodology to guide customers through the application project life cycle. The Business Analyst Case Study training focused on what Business Analysts need to do in the early stages of a project. In the training and methodology the use of Business Process logic was heavily stressed.
Many customers today are using Business Process’s as the basis for designing changes associated with the Out of the Box Oracle Siebel CRM application. The Oracle Siebel implementation methodologies have always incorporated Business Process Design Workshops as a way of collecting user requirements. In years past a Siebel 7.5 Business Process Solutions Library was available documenting the processes built into the Out of the Box Application. This tool helped customers understand what they purchased. As the Business Process Solution Library does not reflect changes to the application made in the latter release of Version 7 and 8 of the Oracle Siebel CRM product its current value is questionable.
One of the benefits many of our consulting partners bring to a project is their own Business Process documentation. Libraries of documentation identifying standard Oracle Siebel CRM processes save the time of developing them for each customer. The advantage of using the Out of the Box Business Processes, as a starting point is that the design of a customized solution starts with the purchased product. Customers who start with old Business Process flows run the risk of trying to make Siebel work the way their old systems worked, which accounts for many projects over configuring the product unnecessarily. Starting with the Oracle Siebel CRM Out of the Box Business Processes leads users to a solution that is customized to support their needs but not so customized that it no longer looks like the purchased product. As many customers know, over-customizing the product comes with a high cost and risk to the implementation project.
Yet even with libraries of processes being available, collecting and tracking new requirements and their solutions require external products and lots of pads of paper. As requirements are captured during user meetings meant to review the business processes, they must be entered into requirements gathering tools that have no insight into the Object Oriented architecture of the Oracle Siebel CRM product.
The Business Analyst and Development Team must work together analyzing requirements against Out of the Box functionality, and determine if the requirement can be satisfied with the current application or if changes need to be made. This effort requires the Business Analyst to use the Siebel Tools application to research how the current application is configured and what needs to be changed. While I love using the Siebel Tools application, many Business Analysts find the tool overwhelming and difficult to gain access to, as it requires a software license. Additionally Developers using Siebel Tools find that the product is wonderful for performing configuration changes, yet they find the tool cumbersome when doing an impact analysis researching what is affected by a change to one of the objects in the Tools Repository.
So, what do we do about this?
I have begun development on an Oracle Siebel CRM Client application add-on that would enable Business Analysts to research functionality in a more friendly fashion. With this tool the Business Analyst uses the Client application rather than the Tools application to provide them the information they need to design a solution satisfying the requirement. The Business Analyst using the Call Center Web Client can look at the Repository Application object, drilldown to see Screens configuration, and then drilldown to see View configuration. From the View you can then drilldown to see Applet configuration, and drilldown through the Business and Data Layer objects. These read only views of the repository objects exposed in the client would negate the need of the Business Analyst to use Siebel Tools while giving them access to Objects they are taught in the standard Oracle University Siebel Fundamentals for Business Analyst course. The heavy use of Drilldowns makes it easier for the Business Analyst to understand the relationship of objects in the Siebel Repository and review the application configuration.
While Business Analysts may find this to be a friendlier User Interface for read only access to the repository, it does not solve the problem of requirements gathering. So we move on to Phase II of my project. Currently I am working with our consulting team to review my first prototype application that collects requirements from within the Call Center application. Once collected, the requirement is associated with activities that distribute any Design Analysis tasks to members of the project team. The requirement is easily associated to objects in the Siebel Repository providing a higher quality requirement specification with tracking capabilities. With this tool it is easy to see what requirements are associated to the same repository objects giving Business Analysts and Project Managers a better insight as to where they will spend their time customizing the application.
The Requirements gathering component that I developed makes use of the Help about View feature of the Oracle Siebel CRM application and the new 8.0 Task User Interface. I envision a Business Analyst running a Business Process Workshop collecting detailed level requirements would open the client software used for demonstrating the application and use it to also collect application requirements.
Suppose during the discussion of a user requirement, the Business Analyst would navigate to the View in the application supporting the step in the business process under discussion. Using Help About View the Business Analyst then copies the information presented in the pop-up applet to the clipboard. The Analyst from the User View would then start up a Task from their Toolbar that would temporarily replace the application View with a requirements gathering process.
Following the steps in the Collect a Requirement Task/Process the Analyst enters information tracking the change request by the user and pasting in the help about view information identifying the objects affected by the request. Features in the Task UI would enable priority and status of the requirement to be collected along with the requestor’s contact information.
After the workshop no transcribing from paper to a requirements gathering system would be needed. Instead the Business Analyst and Development team would review the unprocessed requirements collected in their database, analyze each one, develop activities needed to allocate the design work required and associate the requirement to objects in the repository.
This approach would result in more detailed Design Solutions with the ability to sort requirements by priorities and functionality. As more customers take advantage of Out-Sourcing development services, the need for detailed level design solutions grows in importance. If your development team is not local, you need to ensure that they understand not only what you want to accomplish, but also, how you want the problem solved. Customers who write better Design solutions can lead developers to solutions that are more easily upgraded, saving them significant costs over the lifetime of the application.
The final stage for this set of tools is the development of a Data Warehouse integrated with the Oracle Business Intelligence product. Imagine if Repository data identifying your application configuration and its customizations was integrated with Requirements gathering and Project Management tracking data. Suppose all this data was integrated into one Data Warehouse. Business Analysts and Development staff could monitor the status of a project, analyze how changes affect other components of your deployed application, and identify development team productivity. Consolidating all of this information with a powerful Analytic Query Tool would also allow for analysis of risks before an upgrade and analyze the impact of a change. A forecast of needed time to solve a requirement based on past performance could also be determined through queries of past project metrics.
Those of us in the Information Technology departments of our company have relied on Analytic products to help us improve our Business staff access to information, yet we have not looked at how the technology could help us improve our ability to bring projects in on time and budget.
I believe that a well run Siebel project needs to collect appropriate Project data from the beginning to end of our implementations, and relate the Project data with Repository data to understand the extent of the work performed. Organizing this information in a Data Warehouse, with an Analytic front-end, would give Business Analysts, Project Managers, and Developers the information they need to make more informed decisions. Better decision in the Design Stage enables us to significantly cut design costs, improve design quality and reliability, and use old projects to explain where the bottlenecks and costs are for new projects not yet begun.
I am all to familiar with the old saying about the Cobblers children having no shoes or the Plumbers wife always complaining about the clogged sink. We in IT need to get creative, and internally utilize the tools we provide to the Business, to make ourselves more affective, and to make our lives easier as well.
If you are interested in participating in my proof of concept and would like access to the prototype solution, feel free to contact me and provide the name of your Technical Account Manager who can participate in the use of the new tool.