by ·0 Comments

Let’s face it. Cloud computing isn’t on everyone’s wishlist for 2019 and beyond yet. Organizations are slowly charting the path to Cloud but nobody is really there except of course the Cloud providers themselves

Why?

Cloud computing worked well for batch operations or high-performance computing. But for someone looking to port their on-prem applications to Cloud, the strategy didn’t quite hit the right notes. In other words, for Stateful frameworks there is still some ground to cover.

Another important observation is that Cloud computing advocated the exclusion of physical infrastructure but those who moved were left to fend the management of the virtual allocations to themselves. This didn’t go down very well.

Amazon saw early success with its EC2 webservice. The simple web service interface found many takers and developers found it easy. The key was to have the same look-and-feel in the cloud as their local PCs. EC2 made this possible.

However developers had to manage the virtual machines themselves. They had to learn the system administration or work with the Admins to manage the environments. This took a toll on the developer’s time. For example, writing a simple login-password page and getting it on the Cloud took more time than writing the code itself.

EC2 was a great start. But organizations started feeling the need to simplify the path to Cloud.

Welcome AWS Lambda or Welcome to the world of Serverless computing.

“Run code without thinking about servers. Pay only for the compute time you consume”

Hold on. Serverless computing does not mean any servers! I know the term is confusing. All it means is that the developer writes the code, and the administration is handled by the Cloud provider. In other words, serverless allows developers to code applications without being worried about the infrastructure and implementation needs

Eh? Isn’t this what Cloud computing is all about?

Yes. This is how it has evolved over a period of time.

Serverless computing gave rise to the concept to Functions-as-a-service (FaaS).

AWS Lambda was the first public FaaS offering by a large vendor. Soon  Google Cloud Functions, Microsoft Azure Functions, IBM/Apache‘s OpenWhisk (open source) and Oracle Cloud Fn (open source) followed

FaaS is every developer’s dream. The founding principle is to allow developers to execute code in response to events without maintaining a complex infrastructure. In simple terms, one can upload modular chunks of functionality into the cloud that are executed independently.

Instead of managing a server for load management, the server can now split into a bunch of functions which can be scaled automatically and independently. Microservices, anyone?

Imagine this scenario.

  1. Your existing system is running well. Status quo.
  2. Suddenly, you are asked to spruce it up but the ask is not easy. Fitting the requirement into the existing system is tough
  3. What do you do?

Three ways

  1. Spend endless hours and “dirty-code” the requirement. System reliability goes down south
  2. Take the requirement. Build something wonderful from scratch and then worry about future updates
  3. Use AWS Lambda and fit it in. Okay, I am making it sound simple. There is effort involved here as well. But the upsides outweigh it

Why is option 3 attractive? AWS Lambda takes care of future needs of scalability and performance.

Serverless computing / FaaS is gaining acceptance. If recent surveys are to be believed,  24% of serverless users were new to cloud computing.

So, what’s in it for anyone to go serverless?

  1. Increased fault tolerance. Highly available
  2. Scalability is better managed. Your functions can scale independently instead of your entire application
  3. Modular blocks of code. Ready to ship
  4. More developer focus. Write the code
  5. Infrastructure is handled by the cloud provider

Anything to worry yet?

Not really. Serverless / FaaS has to mature and the acceptance increased. Common myths around security, performance, cost, vendor lock-ins, etc have to be addressed objectively

Also, Serverless / FaaS is not the answer to all your problems. Frameworks and Architecture will continue to evolve. The objective of any software programmer is to complete the code efficiently. Leverage the available trends and best practices

Closing notes

It is promising to see the evolution of simplified programming frameworks combined with making the cloud more approachable. The key is to increase Cloud adoption while at the same time ensure the accountability model is well laid out.

Serverless / FaaS adaption will increase. The opportunity exists. The advantages too. Hybrid approaches are always do-able for regulatory requirements concerning public or finance data.

“Houston, we have a problem” is not the order of the day anymore

“Work the problem” is.

References

  1. Cloud Programming Simplified: A Berkeley View on Serverless Computing
  2. An Introduction to Serverless and FaaS (Functions as a Service)
  3. Monolith Vs Microservices Vs Serverless — The Real Winner? The Developer

————————————————————————————————————–

Devarajan Mukkai is the Chief Development & Delivery officer at Forsys Inc, a global technology firm, specializing in Cloud and Analytics, SCM, ERP Financials, Customer Experience and Relationship Management, Quote-to-cash and Data Migration. Forsys’s clients range from mid-sized companies to Fortune 500 brands.

Devarajan is passionate about Technology, IT Delivery strategies & frameworks and People Advocacy. He has been in the trenches and led from the front for over 20 years. Devarajan works with teams, to lead the clients they partner with, to new heights. Devarajan likes getting people excited about the things he is excited about. And right now, that is everything in tech!

Outside of work, Devarajan is an endurance cyclist, ukulelist and percussionist. His passion for tech is only rivaled by his passion for cycling & music.

——————————————————————————————————————-

Blog post by: Devarajan Mukkai Chief Development and Delivery Officer at Forsys Inc.


by ·0 Comments

Among the core processes and problems of Configure-Price-Quote, configuration-related problems tend to be the most complex. Product modeling has been one of the earliest applications of Artificial Intelligence due to its complex nature. The history of the challenges and evolution of configuration systems from simple rule-based systems to knowledge-based systems is an interesting read in itself. The earliest versions of configuration systems revolved around solving the problems of

  • reducing invalid configurations
  • mass customization of the products
  • the maintenance involved in product operations.

A product configuration or a bundle consists of a set of components, attributes and a set of constraints that need to enforce the validity of the product configuration. All the current industry-leading CPQ systems support the set up of the product configurations using components, attributes, and constraints through the terminology and way they evaluate the constraints that might differ.

Below are the set of users usually involved in the configuration setup & process.

  1. The product managers/marketing teams that define the product configurations/packages/bundles.
  2. The operations team setting up and maintaining the bundle’s rules through the product life cycle
  3. The sales user or sales engineer who actually configures the product as part of the quoting process.

Let’s look at some of the questions that would help us in defining the product configurations for sales in a better way.

  • What should constitute the base package of a product configuration that acts as a starting point with the required defaults? Assess this well as you may have different starting points of a base package based on the type of customer, industry etc and improve these starting points continuously
  • Should you create a different base package or manage the variations through rules? Look for an answer that balances the impacts of sales experience, operations maintenance, and future product configuration needs.
  • What are the driving points for the add-ons offered as part of product configurations? Current CPQ systems would need you set these and manage these manually today as part of a bundle or static recommendations instead of closing this loop automatically through recommender systems that work well for the B2C industry.
  • Are there too many variations of the product that would cause confusion than ease the sales process? Look at the reasons why you are creating these variations and if the reasons are not to sell more and efficiently, those variations need to re-looked at. Never let the systems and operations negatively impact the sales ability to find the right product/solution easily.
  • How do I find top selling/industry-specific solutions and Is it worth to create separate packages for these to improve the sales? This is another area where current B2C recommender systems can solve the problem to some extent by closing the feedback loop to create the top-selling solutions automatically.
  • Do you have the context of the type of user in mind when designing the user experience? How is the user experience going to be in terms of finding the right solution, right alternatives, up-sell/cross-sells, configuring the solution, etc? This also largely depends on the CPQ system that you select and most of them today have limited options to deal with personalization.

please share the challenges you have faced when defining or maintaining product configurations for your company.

Blog Post by Sudha Krishna Sunkavalli Vice President, Cloud Solutions at Forsys Inc, Quote to Cash Processes & Solutions

by ·0 Comments

In this competitive world, quick and accurate order promising is the key to retain existing customers and to attract new customers, Oracle Global Order Promising acknowledges quick delivery promises that your customers can rely on.

Oracle’s global order promising capabilities comprise of robust support for distributed global order promising and multi-level supply-chain from available to promise, capable to promise and capable to deliver.

A user can consolidate supply and demand information from multiple transaction systems to provide a consolidated global picture of demand and supply. Also, order promising is accessible from multiple order entry systems or order capture systems such as web stores and call centers.

Salient Features 

  • Promise orders based on material availability, manufacturing capacity, transportation capacity and supplier capacity – Available to Promise (ATP), Capable to Promise (CTP), Capable to Deliver (CTD) 
  • Supports complex multi-level CTO models, multi-level ATP check configuration, combined product family and item ATP 
  • Model the realities of your supply chain: types of supply and demand included in promising; shipping, receiving, manufacturing, and carrier calendars; product and component substitution, ship and arrival sets 
  • Secured integration with Oracle Order Management Cloud Service
  • Source from a wide range of fulfillment locations, including stores, warehouses, plants and supplier sites
  • Promise against both current and future supply
  • Automation of selecting the lowest cost source and delivery method meeting the customer’s needs
  • Prevent delays by splitting order lines or substituting items if required 
  • Control availability of high-demand products by customer or channel  

by ·0 Comments

Do the standard reports from your ERP work?

No, most of the standard reports which are developed during an ERP implementation do not help the financial user(s) during the time of busy month-ends or for any analysis.

Generally, the reports are run in ERP systems but get published in Microsoft Excel to perform calculations and reviews. This is a very time consuming and tedious process.

Why do we need Smart reports?

Now, when the business expands, the demand for new reports from the Finance department also increases during quarter-end and year-end. At times, the Finance department sends the request to the IT department to develop new reports which comes with a heavy cost. By the time a report is generated after testing, a new request arises and leads to errors in a reconciliation and communication gap between IT and Finance team. 

Oracle Fusion has introduced an Excel Ad-din known as “Smart View” which gives the flexibility to develop reports in MS Excel.  It is a user-friendly tool where a user can connect to  Oracle through Excel and create their own reports. 

The following are some of the key features of “Smart View”.

Essbase Database: Smart view reports are linked with Essbase database of multi-dimensional cubes.

Drag and drop:  It is a simple way of creating reports, right-click on any dimension, drag and drop to choose as column and row. This is an easy way to finalize the rows and columns in the report
Zoom In -Zoom Out:  This helps in analyzing the reports as a user can click on any column or row and then zoom in to look for detailed information of the child value(s) under any parent account or can summarize a group of values into a parent value by Zooming out.

Pivot: This function helps in creating separate tables by using existing data and allows a user to change columns into rows and vice-versa. 
Keep and Remove Only: This feature is very handy to review and analyze the report if a report has a lot of information on the sheet and a user wish to analyze the specific set of details.  

Cascade: Cascade existing reports based on selected members from POV dimension and generate new reports. For example, a user has a sales report by country and wishes to see the same sales report by state, the cascade function will help generate multiple reports for different states in different workbooks. 
Apart from these, the smart view has many features to create financial reports easily.

by ·0 Comments

ASC606 has many provisions for revenue recognition, but here are the 6 key considerations that will impact the majority of the companies implementing the standard. The considerations are pricing, loyalty, rebates, sales compensation, royalties, and billing. Organizations should check their current revenue recognition practices around these items and understand how it will change with the new standard. Ayara can help to recognize revenue covering these six considerations and ensure compliance to ASC606.

Pricing is one of the key consideration for revenue recognition under ASC606. Companies offer a variety of discounts in the form of volume discounts based on the usage, discounts for bundles in the form of Multi-element arrangement (MEA), and discounts at the time of renewal. These discounts will impact the transaction price calculation. The net price of the transaction after all the discounts is the default transaction price. Any variable considerations will be applied to this price to calculate the final transaction price.

Loyalty points are the customer option for additional goods and services for free or at a discount price in future. If loyalty points result in a material right, then it should be considered as a separate performance obligation. Customer pays in advance for the option and can use it to buy goods and services. The obligation tracks the amount based on the loyalty points earned by the customer. When the customer redeems loyalty points to buy good and services, then the appropriate revenue is recognized for the obligation.

Companies offer rebates to drive the buying behavior of their customers. This will enable customers to buy more goods and services, because the more goods they buy, higher the rebate they will earn. Rebates processed for customers is considered as variable consideration and will be used to calculate transaction price for the sale. ASC606 requires that companies estimate rebate for every transaction and recognize the revenue. The transaction price can be adjusted based on the actual rebate processed, or for any changes in the rebate.

Sales compensation is the critical component that impacts more than 90% of the organizations implementing the standard. Sales compensation consists of incentives and commission paid to salespeople. These costs are the incremental costs incurred in obtaining a contract. The cost should be capitalized and amortized over the period of the contract if the contract duration is more than one year. The cost can be expensed if the contract duration is less than a year. This is a big change in the standard as the cost capitalization is optional in the current standard (ASC605).

Sales and usage-based royalty are a variable consideration because the royalty is paid after the sale or usage of the licensed IP. The variable consideration is calculated based on the expected-value method or the most-likely-amount method based on the business scenario. There can be scenarios where the contract is negotiated for minimum guarantee amount. In this case, the minimum guarantee amount can be recognized first, and then any additional revenue for royalties received based on the sales.

Discount given on the invoice for early payment or for any other reason should be considered as a variable consideration and will be used to recalculate the transaction price. This will ensure that the revenue recognized is in sync with the invoice discounts given at the time of payment. The practical expedient provision in the standard will enable customers to recognize revenue based on invoiced amount in some scenarios. The future articles in the series will discuss each of the six considerations, and how Ayara can help implement the standard and expedite the process.

by ·0 Comments

Rebates are the incentives given to customers to buy or consume more goods and services that will meet the rebate criteria and earn the rebate amount. Typically rebates are offered in multiple tiers with higher tiers offering larger rebate amount which will encourage customers to buy more goods and services. Because rebates are a future consideration promised to customers they are treated as variable consideration in ASC 606. The following are the provisions in the standard that give guidance about rebates considered as variable consideration.

When quoting for a product/service that is eligible for a rebate, the rebate tiers are mentioned for the product/service. These tiers can vary by customer or for each quote. The new standard requires that the variable consideration for rebates be stated in the revenue contract explicitly. It is important to identify the contract and the rebate amount for each sale. “The expected value method” and “the most likely amount” are the two methods of estimating the rebate amount. “The most likely amount” is the preferred method used by many companies.

In “the most likely amount” method, the rebate amount is determined by rebate tier which the customer is most likely to meet the criteria. Based on the tier the estimated rebate amount is calculated and is treated as the variable consideration for the sale. The estimated rebate amount and the standalone selling price of the product/service are used to calculate the transaction price that will drive the revenue stream. Since the calculation is based on the estimated rebate, an adjustment is required for the revenue after the final rebate calculation.

The actual sale or consumption of a product/service is tracked by the customer orders that will give the quantity sold during a rebate period, which is typically a month or a quarter. At the end of the period, the rebates are processed for the sold quantity that will determine the rebate tier for actual rebate amount. If the actual rebate amount is less than the estimated rebate amount, then the difference between the estimated and actual amounts is recognized as an additional revenue. If the actual rebate is more than the estimated amount then the recognized revenue is adjusted accordingly.

Estimating rebate amount at the time of sale and subsequent adjustments based on the actual rebate amount can be challenging. Ayara can simplify the process and streamline the revenue recognition for ASC 606. This will enable businesses to have a view of estimated rebates, revenue adjustments, and recognized revenue for each period by product, by legal entity, and any other criteria.

by ·0 Comments

From January 2018, companies in the US have to report their revenue according to the new Accounting Standards Codification (ASC) 606. The new standard is the joint effort of the Financial Accounting Standards Board (FASB) and the International Accounting Standards Board (IASB). US companies will follow the ASC 606 standard issued by FASB while companies outside of the US will follow the International Financial Reporting Standards (IFRS) 15 issued by IASB. Both ASC 606 and IFRS 15 have the same revenue recognition framework that will enable large multi-national organizations and SME businesses to report revenue consistently.

Many factors influenced the introduction of the new revenue standard which will standardize the revenue reporting across the world. The three key drawbacks in the current standard are:

The current revenue standard is complex to interpret and implement as there are couple hundreds of pieces of literature that contributed to the standard. The old standard (ASC 605) focus on few industries and transactions, but there is no guidance on revenue recognition for other industries. This gap in the standard makes revenue recognition requirements inconsistent across industries and transactions. This will make it difficult to compare revenue between similar industries or across industries.

The old FASB and IFRS standards for revenue recognition are not consistent, which made revenue reporting difficult for global organizations. Because of the difference in the old standards, it is not possible to compare revenue of a US company and a non-US company from the same industry. The new revenue standard (ASC 606 / IFRS 15) will eliminate the differences in the standards, provide a robust framework for revenue recognition, and simplify the reporting requirements.

The new revenue standard is an opportunity for the companies to relook at their current revenue recognition business process and re-engineer it to drive operational and financial efficiencies. The process will also enable them to comply with the legal reporting requirements. Organizations should consider a cloud-based revenue recognition solution like Ayara that provides end to end solution for the ASC 606 implementation. Ayara is easy to implement and offer flexibility to make quick improvements over a period as companies refine their business process to implement the new standard.

by ·0 Comments

The US Government has increased rules and regulations for manufactured products and processes of various industries. It is mandatory for manufacturing companies to keep detailed records of their processes, inventories and designs. However, the trend for bookkeeping in these companies has been manual and traditional over the years. 

The trend is changing now as more and more companies are willing to maintain and store their records in the electronic format. This shift has reduced paperwork and helped companies to achieve compliance with the US Food and Drug  Administration’s (FDA) 21 CFR Part 11 regulations. 

Now, Oracle for Electronic Signatures and Electronic Records provides a configurable framework for securely capturing, storing, retrieving and printing electronic records and signatures. The critical business events in Oracle Supply Chain Management have been enabled in the areas of product design, inventory, manufacturing, quality, purchasing and shipping.

  • Manufacturing Standard Operation Management
  • Work Order Material Transactions 
  • Work Order Operation Transactions, and
  • Order less Transactions

Let’s understand how this helps a company from a manufacturing perspective and enable electronic signatures for the below: 

A user can review electronic records that are generated automatically and capture electronic signatures inline for standard operations as well as for work execution transactions. And in addition to this, a user can also search and retrieve the related E-records through the electronic records work area.

Manufacturing Standard Operation:

The e-record which gets generated automatically for a standard operation contains the following information:

  • Standard operation details
  • Resource details
  • Alternate resource details

Work Order Material Transactions:

The e-record which gets generated for a work order material issue or return transaction contains the following information:

  • Work order details
  • Operation details, and 
  • Material transaction details along with material lot and serial details

The process to generate an electronic record and capture electronic signatures is initiated only when an operation transaction is submitted using Quick Complete or Complete with Details actions in the review dispatch list page or manage supplier operations page. 

Work Order Operation Transactions:

The e-record which gets generated for a work order operation transaction contains the following information:

  • Work order details
  • Operation details
  • Inspection details
  • Operation transaction details
  • Product transaction details with product lot and serial details
  • Backflush material details with a material lot and serial details

Also, it’s important to note if multiple transactions such as complete, scrap and reject are reported through a single user action, then a single electronic record is generated which contains transaction details reported. 

Order less Transactions:

The e-record which gets generated for an orderless completion or return transaction contains the following information:

  • Order less transaction details
  • Inventory transaction details along with product lot and serial details, and
  • Backflush material details along with material lot and serial details

Once a user enables E-signatures and E-records for standard operations management and work execution transactions, the inline E-signature capture process is initiated when the transaction is submitted for approval. E-records are generated and the electronic signatures are captured before the transaction is saved. Notifications are sent to the approvers, which can be accessed through the bell notifications in the Oracle cloud application or through email. The approvers can review the E- records before adding their E- signature. Approvers can add their comments, indicate their approval or rejection and sign the E-record by entering their password. 

The approvers also have access to view the current status of the approval process through the approval history region in the inline signature capture page and in the notifications. The standard operation creation or update or work execution transaction is either saved or rolled back and is dependent upon the approval outcome. 

A user can search and retrieve electronic records in an e-record work area using multiple search criteria such as the contents of the report title, the transaction type, organization, last signed date or status. It is to note that the e-records are stored in a secured document repository and cannot be modified or deleted. Though, Oracle E-signatures and E-Records stores both the approved and rejected records.

by ·0 Comments

Forecasting accurate revenue is a key capability that companies want from their QTC investment. In majority implementations of QTC, customers forecast revenue from opportunities in pipeline and order bookings. But these forecast numbers are not accurate as the revenue numbers can change before opportunities are converted into bookings, and bookings may not reflect the right revenue allocation and variable considerations. Since revenue forecast is important for companies to make strategic decisions and give proper guidance to markets, there should be a reliable method to forecast accurate revenue.

Companies need accurate revenue numbers at an early stage in QTC process. Typically they need the data at least at the time of creating a quote. This will not only give them early visibility to revenue forecast but also address a key pain point where a sales person will book a deal at a lower margin (sometimes negative margin) without approval from the finance team. With revenue visibility at the time of quoting, margin can be calculated and appropriate action can be triggered for approval before finalizing the quote.

No alt text provided for this image

There are three components of revenue intelligence for CPQ. The setup required to calculate revenue and display on the quote. Allocate the revenue based on predefined rules, and finally generating the forecast. The allocation and forecast will be processed when creating a quote, and presented to the user before finalizing it. The allocations and forecast will be regenerated every time a change is made to pricing or the attributes of a quote are changed. This will ensure that the revenue forecast is in sync with latest changes on the quote.

Revenue Intelligence process

The process is triggered with quote creation in CPQ which will determine the transaction price (net price minus variable consideration). The transaction price is used as the basis for revenue allocation based on preconfigured rules or formulas. The CPQ system can now determine the actual margin (revenue allocation minus cost) for the deal. The calculated margin can trigger a workflow for approval if its below a threshold level. The revenue is forecasted for the duration of the deal to show the revenue spread for each period and can be reported for further analysis.

Revenue intelligence will give the control to users over the margins they want on each deal, and will give an accurate revenue forecast at an early stage in the QTC process. This will help the management team to make strategic decisions and give reliable guidance to stock market and share holders. Ayara  provides revenue intelligence functionality that will integrate to any CPQ (Salesforce, Apttus) system, and gives the revenue forecast visibility on the quotes. It will update the forecast based on the quote changes and ensure that forecast is correct and recognized revenue is accurate.

by ·0 Comments

Configure-Price-Quote (or #CPQ) is a critical function in most organizations, but many businesses seek better tools to implement effective quoting strategies. New #middle-office solutions are bridging gaps between an organization’s front and back office systems that have existed for decades. Having been engaged for nearly 15 years with addressing quoting challenges through custom and packaged solutions, I have documented the most common issues faced by organizations:

  • Inability to support new business scenarios (subscriptions – hardware or software)
  • Complex sales experience in configuring products
  • Lack of guidance for Sales on discounts to win the deal
  • Discount leakage and lack of visibility to Sales & Finance
  • Inadequate approval functionality with no visibility and audits
  • Lack of information architecture
  • Products and pricing data duplicated in multiple environments with no clear “source of truth” and increased operations overhead.
  • Product / SKU & Price list proliferation
  • BOM explosion between Quote, Order and Manufacturing
  • Manual Orders (lack of quote-to-order integration)
  • Out-of-sync Quote and Order

Organizations can capture strategic opportunities by standardizing their quoting business process based on best practices and by enhancing tools & systems.

What are some of the quoting challenges faced by your organization ? Tell us !

To discuss these and other issues related to Quoting, Pricing/Discounting, Configuration, Approvals, Contracts, Order, Billing, B2B ECommerce & Revenue, join Quote to Cash group.

Author : Srinivas Vemuri, COO and SVP Cloud Solutions @Forsys inc.