Package Implementation Vs Software Development
Having been involved primarily in software development, I don't really understand how package implementations work but I came across some useful material today which talks about a typical CRM implementation. The methodology is:
Define(what you want)->Discover(detailed reqts)->Design(solutions tailored for the process)->Configure(the package)->Validate(that it does what you want)->Deploy.
The key difference from s/w development is in the Configure and Validate process. Interestingly, there is a lot of stress on trying to meet the user reqts with the available functionality; customization is frowned upon and, if unavoidable, should be kept under 20%. My own guess is that if you customize > 10%, you may be going dangerously off-track. Makes sense in a way because it is, after all, a package and not a panacea.
Also, there is a lot of stress on making sure that reqts gathering sessions are focussed around fitting the user reqts into what is available in the product and to steer clear from gathering user wish lists for features!
I may be wrong here but, in a previous assignment, I was discussing Siebel reports with a user who was involved in a data warehouse project; she wanted some of the Siebel data to be pulled out and presented in a DW through a standard reporting tool. I asked her why she couldn't do it in Siebel itself (the reporting looked very slick after all) and she said (if I understood correctly) that in Siebel, every report (or applet in Siebel terms) is tied to one underlying Business Object (such as Account or Orders) and any customization is limited to showing/hiding attributes of that underlying object.
So, if I want a report showing some fields of Orders and not others, yes, that is possible. But, if I want a report that showed attributes from different Business Objects (for example, Order details along with Customer Name, Customer City, Customer State, Customer Country, say), that is not possible because the information may be spread across several Business Objects.
Define(what you want)->Discover(detailed reqts)->Design(solutions tailored for the process)->Configure(the package)->Validate(that it does what you want)->Deploy.
The key difference from s/w development is in the Configure and Validate process. Interestingly, there is a lot of stress on trying to meet the user reqts with the available functionality; customization is frowned upon and, if unavoidable, should be kept under 20%. My own guess is that if you customize > 10%, you may be going dangerously off-track. Makes sense in a way because it is, after all, a package and not a panacea.
Also, there is a lot of stress on making sure that reqts gathering sessions are focussed around fitting the user reqts into what is available in the product and to steer clear from gathering user wish lists for features!
I may be wrong here but, in a previous assignment, I was discussing Siebel reports with a user who was involved in a data warehouse project; she wanted some of the Siebel data to be pulled out and presented in a DW through a standard reporting tool. I asked her why she couldn't do it in Siebel itself (the reporting looked very slick after all) and she said (if I understood correctly) that in Siebel, every report (or applet in Siebel terms) is tied to one underlying Business Object (such as Account or Orders) and any customization is limited to showing/hiding attributes of that underlying object.
So, if I want a report showing some fields of Orders and not others, yes, that is possible. But, if I want a report that showed attributes from different Business Objects (for example, Order details along with Customer Name, Customer City, Customer State, Customer Country, say), that is not possible because the information may be spread across several Business Objects.
Labels: Siebel package implementation DW
posted by Ram at
11:28 AM
0 Comments:
Post a Comment
<< Home