Raja Ivaturi - Oracle Savvy

How do you measure ROI for SOA?

2011-11-16T18:58:00.001-08:00

Now that the world is coming in terms of deploying Service Oriented Architecture (SOA) as a strategic solution for better gains in the business and agility, the question comes on how to measure the benefits.

Probably you first need to be clear on what you wanted and how you wanted to measure that paramater(s) and then verify where you were before adopting SOA. After every milestone and complete adoption, keep measuring to understand whether you were in right direction.

There are various ways on measuring depending on what were your objectives. Major objectives could be cost savings or improvement in revenue and your agility. While the cost savings are easy to measure, the amount of agility achieved is a bit intangible but can still have a correlation with some measures.

There are two ways to measure the ROI .

1. Effort Redution

You have the estimates for the work that you have been doing. Now after implementing SOA based solution verify the improvements based on amount of efforts reduced in the areas of work sheet.

Major dimensions identified are as follows:

Reuse: The focus of Service oriented architecture is on reusing wherever possible. You can compute the cost savings through tracking the number of service reuses and the amount of cost saving.

The cost saving could be

* Saving in Cost of development of service

* Saving in Rework (the services are already tested and proven and hence the defects will be less)

* Saving in documentation efforts (Designs and deployment documents already in place and may need only minor updates)

Savings in Integration: The integration through SOA Approach is more quick and efficient as well as less error prone and maintainable, compared to the point to point integrations. You can objectively measure the savings in integration in terms of

* Reduction in Number of Interfaces required without SOA and

* Reduction of effort in rebuilding each Interface corresponding cost savings

* Reduction in testing and reworking on each of Interfaces

* Reduction in Interface Maintenance Costs

* Reduction in Documentation efforts

The savings will increase as you have more and more applications involved in the integration using SOA.

Cost Savings from SOA monitoring and management: With SOA Management functions of your techstack, you can manage the common software problems without much human intervention across the network, with alert mechanisms when exceptions occur.

* Cost savings from reduction of Skilled resources

* Cost savings from quick alerts and resolution of exceptions

Hardware Savings: It is best practice for any Project Manager to take the details of existing Hardware used by the customers before adopting to SOA solutions to assess the hardware savings through consolidation and creation of framework with lot of common services and components.

Cost of Hardware reduction and maintenance
Intangible benefits of being more ECO friendly by consuming less Hardware utilities

2. Revenue Improvement

The Combination of Process Orchestration and real time business intelligence with robust process management capabilities, the business will get improvements in revenue side apart from the cost reductions.

Depending on the business that you do, you can compute the improvements in some of your Key performance indicators to identify the benefits from SOA.

For example, the real time intelligence coupled with intelligent actions for correction and address the alerts, can provide some of the following benefits:

1. Improvement in Delivery performance

Example: Your Production shop completed the Turbine but the delivery team didnt release the item to customer. An alert from Real time business intelligence tool can make sure the item is delivered on time and reduce your storage costs and on time delivery performance.

Collect the data and calculate the improvement in delivery performance.
Also calculate the savings in storage costs which improve the profitability
Collect ths stock outs per month and calculate the improvement.(Stockouts are reduced due to real time alerts for correction)

2. Improved Inventory turns due to direct integration between businesses

3. Quick and error free mergers and integrations save lot of down time costs and provide you the revenue opportunities due to quick entry of merged versions in to market

4. Improved Customer satisfaction index and expantion of customers

Count the new customers in each period
Compute santisfaction index

You can quantify the benefits in the same way in all functions of business such as HR, Design, Order capture and management, customer care, Sales, Finance, Marketing etc.

Track configuration details of PTO models when shipped Partially

2011-11-09T18:52:00.000-08:00

Business Scenario

The configuration relations are not created for PTO Configurations when a shipment occurred through partial shipments When the PTO model and options (all tracked in Installbase) are delivered with partial shipments, the instances of tracked components and PTO model are reflected in Installbase; the relationship between PTO model and components is not created.

Why it behaves

When a PTO order is partially shipped, the backordered lines are identified as remnants in Order Management and the system ignores the relationship between the lines and treats each individual item as separate shipment. After the model becomes remnant, IB cannot create component relationships.

Solution /Workarounds:

WorkAround 1. It is recommended to deliver with the Ship Model Complete checkmark selected for the tracked PTO Models; execute the pick and confirm only after the last shipment is made.

This is not a good work around when most of the times your business doesnt work with ship model complete scenarios, but it avoids a lot of overhead, in terms of manually updating the configuration details in Installbase if partially shipped. You need to remember and record the shipment after last shipment is made and it puts lot of manual tracking. But this alternative can be handy when the PTO model has huge number of components.

Other issues with this workaround is that the business intelligence reflects poor delivery as you execute Pick and confirm only when the last shipment is made.

WorkAround 2. Manually maintain the relationship in the Installbase, after the last shipment of the partial deliveries is complete.

For manual updating the instance configuration, you may refine the process by defining a new transaction sub–type, which indicates that the parent configuration of these instances needs to be updated.

An example setup is as follows:

a. Create a new instance status 'Update Parent Config' with the same attributes as the instance status 'Created' and change the status description to 'Update Parent Config.' This status indicates the user that you need to update the parent configuration in Installbase.

b. Create a Service transaction Billing type similar to the seeded type Sell but rename it to 'Sell with Partial'. This indicates you are making partial delivery and need additional action.

c. Create the transaction sub-type, with the seeded service transaction type ‘Sell Partial’ included from the LOV, of name. Assign the new status created in step a, ‘Update Parent Config’ to the transaction Sub-type.

d. When you ship the components of PTO model, go to the installation details from the actions menu of the sales order line and change the transaction sub-type to the new transaction subtype (Sell with Partial.) In the external reference mention the parent PTO model name which needs to be updated with the shipped item as component.

e. After completing the last shipments, periodically qurey for instances with status as 'Sell With Partial' and identify the parent PTO to update from the external reference.

f. Update the Parent PTO model with the instances shipped later.

g. Update the component instances with status Created (which is the original status description for the shipped item for the first item)

This is a cumbersome process but can be opted when the configuration does not have too many components

Note: You may use the Open Interface to execute the configuration updating, when there are too many shipments.

How can we configure item in Selling Organization, without BOM in the Organization

2011-11-09T18:44:00.000-08:00

Business Scenario:

The Multi-Company Organization has a selling organization S1 which sells the configured items made in the organization M1. The Sales Rep doesnt keep BOM and Routing of the Configured items in the Sales organization as they dont make the items in S1. But they want to Configure to choose the options and arrive at the configuration before asking the Manufacturing organization to make and supply to S1 to subsequently deliver to the customer.

Solution:

In R12, this scenario can be dealt with the below setup.

1. Define all the ATO Models in the organizations M1 and S1

2. Define the BOM in M1 and in the OM Validation Organization. (Assume O1)

3. Set the item attribute Create Configured Item, BOM as "Item Based on Model, BOM Based on Soucring"

4. Define Item-Org Sourcing rule for each ATO Model in S4, for Transfer from M1

5. Define the Internal Sales order set up for transactions between M1 and S1

6. Define the transfer from sourcing rule in S1

7. Go to the System Profiles and check the default Assignment set that is mentioned in the Profilt MRP:Default Assignment Set.

8. assign the transfer from sourcing rule to S1 and to the item of your purview.

The transaction works as follows:

1. Sales Rep receives the order for a ATO Model

2. Make the order entry with S1 as the Ship from Org

3. Launch the configurator, even though BOM doesnt exist in S1, the configurator picks the the OPtions from the BOM defined in the OM Validation Org

4. Choose the options and return to order management

5. Book the sales order

6. Create configured items (through Progress order)

7. Autocreate Supply eligible (through Progress Order)

8. An internal Sales order is created with source as M1

9. Make the Configured item in M1

10. Complete the Internal Sales order process

11. Ship the item from S1

2011-11-05T22:20:00.000-07:00

Solution- Sensing devices with flexible discounting and Unique configured item identity

Contributor: Raja Mohan Ivaturi

I came across a customer assembling and selling the sensing devises and had the following business scenario to be supported by Oracle E-Business Suite. Your feedback is requested.

The Business Scenario:

The Customer makes the end items in Assemble / Configure to Order scenario with many optional sub-assemblies and options components.

1. Customer sells various combinations of the optional items and assembiles under the generic Bill of the end items based on the choice made by the customers at the time of order entry

2. Customer quite often offers discounts to the customers based on certain options of sub-assemblies / components. For example out of options A,B and C of certain part, customer offers 10% discount whenever the customer opts for the optional item A. In the similar manner the customer offers discounts and special prices on many such combinations.

3. The customer identified some popular combinations of these configure to order items, that are frequently ordered, and defined such combinations as Pre-configured items. Through this the customer wanted to have special focus while planning on the popular end items as well s avoid the cumbersome configuration process from hundreds of options

4. The customer also wants to track the sales and performance of each combination from the configure to order items and hence wanted to have unique identity of each item with specific combination of optional items.

Original solution: the customer did the below setup to address the requirements of above scenario:

A. Defined the Configure to order ATO models

B. Defined the discounts in Advanced pricing with optional items as qualifiers

C. Defined Pre-defined items for some of the popular combinations from the ATO models.

However the customer faced the following setbacks.

* Problem 1:

1. Sales Rep enters the Popular item when the configuration selected by his customer is one of the pre-defined configured items to avoid cumbersome selection of large number of optional items through Configurator

2. By Oracle Functionality, the Price of the item is however picked up from the item master as calculated at the time of pre-configured item creation

3. The discounts to be applied on the optional items were bypassed when the pre-defined items were directly entered in the sales order. The price of the predefined item is directly taken and no pricing calculation was taken place as it happens only while new configured item was created. So the customer decided not to use the Pre-configured items and always go through the Cumbersome configuration Process

a. This made the order entry cumbersome (Problem 1: Lengthy Order Entry)

b. Customer lost the visibility on tracking the sales of most popular items as fresh configuration every time even for the same combination. For example if you choose options 1,2,3 in one order an unique configured item A is created and next time when you choose the same items another configured item id B is created and there is no way you can understand that these items A and B are same and ordered more number of times. (Problem 2: No Visibility on the popular configurations)

4. The customer hence decided to bypass the pricing and redeveloped all the pricing definition in Configurator rules with heavy customizations

5. The Prices are calculated in the Configurator while choosing the optional items

6. However the Configurator performance was drastically reduced and selecting the large number of options every time reduced the Order entry and configuration process very long time (Problem 3: Performance Issue)

In summary there are three major issues due to which the customer was not happy even with the Oracle Application offerings:

1. Problem 1: Cumbersome Order entry Process as Pre-configured items could not be used. In case we want to use the Pre-configured items and reduce the Order entry, than the Pricing definition would be bypassed

2. Problem 2: Switching OFF the Match feature and relying on the Order entry plus Configuration Customizations, removed the visibility on the Popular Configurations and doesn’t give Business Intelligence and decision making opportunities

3. Problem 3: Heavy logic included in the Configurator to redo the entire Pricing logic created serious Performance issues

Solution

I provided the below solution with very minimum Customization and meet all the requirements.

1. Set the Configure to Order models as it is.

2. Set the Standard Match ON. The Existing configured items including the Pre-configured items will be picked up whenever the same combination is selected by the customers.

3. Set the predefined items as they are

4. Write the configurator rules to default the option selections based on a value equal to the predefined items. You need to create some non-BOM options referring to which the Configurator rule will make selection of optional items that should go for the pre-defined item

1. While doing the order entry, if Sales Rep knows the item is known popular item, he/she still launches the configurator but enters the first non-bom option (Feature) as the predefined item code.

2. The configurator rules based on this input defaults the optional items. The user need not make the cumbersome selection.

3. Submit the configuration

4. All selected options are loaded as Order Line items under the ATO Model

5. When configured item creation is triggered, the pricing engine looks at the selected lines and apply all the pricing rules defined

6. However the Configuration match function picks up the same predefined item but with the price calculated as per the pricing rules for selected options.

7. Because the match is ON the customer was able to track the sales by unique combination of options (configured item codes) that help the business intelligence and decision making

Finally ensured that all the issues have a portion of solution addressing them by preparing the matrix below:

Highlights

1. The solution has very basic configuration effort in setting up the configurator rules to pre-select the options for Pre-defined items

2. There was almost ZERO Customization

3. All great features of Configure to Order were effectively used

4. All Business Requirements were met to the full extent.