Master Products in Prophet Workspace - Many or Few?

When I worked on Prophet projects that involved setting up Prophet model from scratch or streamlining existing Prophet models, one of the common requests I came across was relating to no. of master products. Many Prophet users have such a perception, i.e. the lesser no. of master products in a Prophet workspace, the better it is.

Let's think about it, is this perception correct? When we are talking about of having a better Prophet model, what does the word "better" mean?

Define a BETTER Prophet Model

It is important for us to define what we expect from a "better" Prophet model, instead of focusing on the no. of master products in the model. Let me share some views if I am a Prophet user:

  • It is easier for me to setup a new product in my Prophet model. I don't want to define 50 - 100 input variables when I setup a new product, especially those input variables that I could not really understand what they are for.
     
  •  When I need to amend coding of an input variable or a core product in the library, the coding is not lengthy and it is easier for me to go through, especially in the diagram view.
     
  • It is always a good thing if I can use a Same As product for my new product. But... I don't want to such convenience comes with updating 20 - 30 tables. I may need to study the coding again in order to update those tables.

It goes back to the efforts required in the model maintenance. One of the rules I have learnt from my actuarial models and solutions development projects, flexibility always comes with complexity - i.e. when we want to introduce more flexibility in a model or solution, we need to always take note that we may be going to introduce more complexity at the same time. Furthermore, it will also invite a lot of redundancy if we want to have a generic model / solution.

Let me give some examples for better clarifications. Try to imagine if we need to setup only ONE master product for all investment-linked products. To do so, we need to include all unit deducting riders with various product features in the master products, so that it be used for all investment-linked policies, either with and without riders.

If you are familiar with Prophet models, every rider needs to have a set of designated variables in defining the product features, including cost of insurance ("COI"), benefit amount, incidence rates, reinsurance premiums etc. - it may require a few hundreds of variables for (say) 5 riders. Yes, the master product is now flexible, but do you think it is a suitable master product for a single premium investment-linked product that is without rider (which is mainly for investment purpose)?

Maintenance in Master Products?

I think it is clear enough that the above-mentioned master product is not suitable for single premium product without riders. A better approach that I would recommend is to create a separate master product for this single premium product - so that we can reduce redundancy in the product and shorten the run time.

Some users may object this idea: "This will increase our maintenance work!" Well, it may sound correct when you first hear such comment. However, the truth is most of the time the master products are not even opened by the users after they are setup and tested. In other words, most master products normally do not require maintenance after they are finalized and promoted to production.

In conclusion, we should not be over concerns on the no. of master products - instead, we should create a separate master product if there are significant different product features (I should discuss the concept of input variables in a separate post). 

If you have two master products which you have only minor differences in one or two input variables (such as different ways of calculating current sum assured), it is correct that you should have only one master product for these two variables.

Comments

Post a Comment

Popular posts from this blog

Other Ways to Prepare Prophet Model Point Files? Try FoxPro!

Image
If you are a frequent Prophet user, you must be definitely familiar with "Model Point Files" ("MPF"), i.e. the policy data that you compile in a specific format that Prophet can recognize as inputs for Prophet runs. If my guess is right, most probably you use Data Conversion System ("DCS") to convert the source data you download from your policy administration system (may be in various format, e.g. fixed ASCII / fixed width, comma delimited, tab delimited, etc.) into the required MPF, based on the definitions you specified in your DCS programs. In case your source data are divided into various files, you may need to carry out more steps to prepare MPF, for example: Open different source files in Excel Combine required fields from different source files by using commands (such as) VLOOKUP, SUMIF & MATCH. You may have automated this process by using VBA. Convert the required files into text files Use DCS to convert those text files into MPF  How...
Read more

How do You Setup Indicators in Your Prophet Model?

Image
In my previous post, I have discussed areas that you may consider in setting up input variables . Before I proceed my discussion on core variables, I would think that it is good for use to take a look on indicators - as indicators play an important role in setting core variables with various formulas (known as "variable definitions" in a Prophet model).  The funny thing about indicators is: it DOES NOT carry any formulas that you need to use in calculating a variable! Basically, they are just some texts that you can combine using different logical operators (AND, OR, NOT), such as "ORD_PAR AND SING_PREM" for a single premium ordinary participating product. 
Read more

How Should I Do My UAT? (1): Program / Spreadsheet / Model

Image
If you are working in the actuarial department of an insurance company, it may not be uncommon to you involving in various testing exercises, which are known as User Acceptance Testing ("UAT") in general. Some of us may think that UAT is only applicable to the policy administration system implementation project (Oops... Do I remind on the non-stop follow-ups from your Project Manager?), but in fact UAT is also needed for the programs, spreadsheet templates or actuarial model we use to perform various actuarial studies - whether they are developed internally or by external consultant. It is particularly important for those tools which we are going to use to perform regular studies. In my view, there is no one right answer for the approach to be used in performing UAT on program / spreadsheet / model - most importantly, the approach that you adopt should allow the required testing to be carried out in a structured manner, and it should not create too much "processes...
Read more