In most implementations, a high number of indexes already exist on some of the tables (such as, S_OPTY) and you must be careful not to add too many indexes. A new index can fix one query but may slow down another. Moreover, each new index adds some overhead to the system and slows down DML statements (such as, Insert, Delete, and Update). It is critical to pick the correct set of columns (both the columns and their order are important) so that the CBO can properly use the index, and the index can subsequently improve performance.
A recommended solution is to index the columns that improve the queries reported by DBA as top queries. For example, if a user is complaining about a slow response time in production, or if a LoadRunner transaction showed a higher average than the SLA, you can use sql tools/performance check tools to identify the activity for that user (or transaction) and identify the top SQL contributing to response time. There is no point in indexing a column that speeds up a query, even if the improvement is significant, if the query is executed only once a week. You should consider adding new indexes that improve queries that consume high database resources, as well as queries that cause end-users to wait a lengthy amount of time for a response.