Planning Analytics and Decision Optimization
This post discusses how Planning Analytics and Decision Optimization can complement and benefit from each other and introduces some simple ways to start integrating them.
Planning Analytics
IBM Planning Analytics (powered by TM1) is a business performance management software suite designed to implement collaborative planning, budgeting and forecasting solutions, interactive “what-if” analyses, as well as analytical and reporting applications. It is available on public and private cloud.
With Planning Analytics Workspace (PAW), it is simple to create Line of Business (LoB) applications using different tabs with different widgets with layouts supporting a collaborative planning process. The configuration of the workspace can be done from within the tool. On the back end side, data is stored using TM1 servers. Also PAW is natively multi user and most widgets supports data edition so that a team of planners can work and edit together a plan until it is satisfactory.
You can read more about Planning Analytics here.
Decision Optimization
IBM Decision Optimization represents a family of optimization software that delivers prescriptive analytics capabilities to enable organizations to make better decisions and deliver improved business outcomes. It is based on Mathematical and Constraint Programming. Decision Optimization (DO) is now available from within Watson Studio (WS) and Watson Machine Learning (WML) as commented in this post describing all the improvements delivered during 2019.
Pros and cons of PA and DO
PAW is very easy to start with. From the web based LoB UI it is possible:
- to create the different cubes and dimensions that will be used by the application,
- to copy and paste some data coming from other sources,
- to create business widgets and organize them with a chosen layout.
PAW is natively collaborative and multiple users can work on plans by editing some of the data in the cubes through the widgets. Some rules can be defined to spread value changes among the different dimensions. For example, a change in production over a given period can be automatically spread to the different plants or to the different products. However the plans may be sub-optimal and nothing ensure they do respect the business constraints.
On the other hand, DO models ensure that solutions to a given problem are optimal and do respect all the constraints that have been included in the model. However, it requires a mathematical model to be formulated and mapped to the business concepts. This is what in general prevents more business applications from benefiting from optimization. Also, while the LoB is the person who will really benefit from the outcomes of DO, the creation of a good business application with good user interface and what-if functionality, is sometimes not given all the importance it requires.
Benefits of Combining PA and DO
So one would ideally like to merge the two approaches. That way it would be possible, through the PAW user interface to manually work on plans, do what-if analysis, while still taking advantage from solutions found by DO models and engines. Indeed, DO might suggest optimal solutions which would not have been tested by humans. DO can also help validate the correctness and/or quality of solutions which have been edited by planners. In the end, what is important is not to have a mathematically optimal solution, but have a solution that is optimal for the business, and hence takes into account the expertise from the planners, which is not always fully captured in the mathematical models. The planning cycles can then be accelerated and the confidence on the plans increased.
How to start?
After the benefits from integrating the different approach is understood, the next issue is about easily start to integrate the tools.
Using do-ws-pa
A prototype of integration service (do-ws-pa) is available which makes it easy to integrate DO models with PA. In fact, the integration service is based on Watson Studio (WS) and Watson Machine Learning (WML). So not only does it enable the integration of optimization models but it can also be used to integrate predictive and other machine learning models.
You can find a ready-to-use Node JS application which implements this integration service in the https://github.com/IBMDecisionOptimization/do-ws-pa github repository.
The architecture of the service is very simple, as represented in the following chart:
The integration service has a back-end and a front-end part.
The back-end part is responsible for connecting the PA and WS/WML back ends. In the production flow, it takes care of extracting the right part of the data from TM1 servers, transforming them into the right structure for being consumed by the optimization models deployed on WML, and then runs the models, and moves the solution back to TM1.
The front-end part includes simple widgets that can be integrated into Planning Analytics Workspace (PAW) as if they were native widgets thanks to the capability of PAW to include web widgets.
It includes a simple development widget with the 5 steps required to setup some integration. For the model development, the data can be pushed to WS where the data scientist will have all the necessary tools to develop, test, debug and tune the models. Then the data scientist will deploy the model on WML.
The five steps to setup and test the integration are hence:
- extract the data from PA, using a mapping that can be configured from within the widget,
- push this data to a WS project , using some specific WS credentials,
- open WS to formulate the model and deploy it in WML ,
- run the optimization, using WML credentials and deployed model id,
- push the solution back to PA.
When these 5 steps are done, the integration is ready for deployment.
The front-end part also includes a simple deployment widget that can be used by the LoB user to run the models on some scenario and then do what-if analysis.
In the deployment widget, LoB can choose input and output scenarios if those have been configured as specific dimensions in the mapping definition.
PAW can be easily configured to include all the widgets to represent the input data, the output solution for different scenarios, the KPIs, and even create some comparison views, showing the different KPIs or solution values for different scenarios.
Using full custom code.
An alternative to this integration service is to write some dedicated custom code. This custom code would ideally be built as a separate service, replicating the architecture presented above. Both PA and WS/WML offer documented standard REST APIs so it is pretty easy to have this service access both of them. As a starting point, you can look at the documentation for TM1 REST APIs and DO for WML REST APIs. The package library do-ws-js used by this integration service can help you to start using these APIs and might be a good place to look at to get some hints.
Conclusions
While this post focuses on adding DO to PA, most application will benefit from several analytics techniques from WS and WML. This type of integration will allow to forecast some demand, cluster some customers, predict some behavior, plan some production and/or schedule some actions.
PS: Thanks to Pascal Viguie who helped me on a few PA topics while developing this prototype.
