Multiple Prophet Workspaces? Combine into ONE!

SCENARIO:
Mr. A, the head of valuation team of Company X, was struggling on how to manage his Prophet workspaces. Due to various constraints (time constraints, resource constraints, ...) in the past, his team ended up using multiple Prophet workspaces in performing valuation exercises - which incurred extra time & efforts in completing required studies. To make the matter worse, some workspaces were actually having the same products (well, the oldest workspace was used to calculate statutory reserves and the latest workspace was used to calculate IFRS reserves...) - his team needed to prepare different sets of model point files for these workspaces because the variables used to read model model point files having different names!

The Chief Actuary was unhappy with this inefficiency in managing workspaces. He requested Mr. A to work out a way to consolidate the workspaces into one workspace, or at least lesser workspaces. The problem is, the Prophet Manager couldn't allocate much time for this unplanned exercise and he didn't have much time in performing UAT...

(Note: Each workspace used only 1 library)

MY PROPOSED SOLUTIONS
If we don't have time & resources in doing proper consolidation exercise on the multiple existing workspaces, perhaps the fastest way in consolidating multiple workspaces is to import libraries into a selected workspace:

  • Select a workspace as the base workspace. There is no fixed rule in selecting a base workspace - basically we can select the workspace having most products or most complicated. For example, if we have a workspace for individual products ("Individual Workspace") and another one for group products ("Group Workspace"), we may want to make Individual Workspace as the base workspace as it is more complicated than the Group Workspace.
     
  • Import libraries into the base workspace. A workspace can have more than 1 library, as long as the first character of the library name is different. To do so, we can select Tools > Import > Libraries. In case the existing library name in the source workspace is the same as the base workspace (e.g. "Conventional" or "Unit Linked", we need to duplicate the library in the source workspace and rename into different name before we import the library into the base workspace.

    For the options to be selected in the "Import of ???? Library" dialog, I would suggest to retain all existing workspace level properties of the base workspace (hopefully we are using the same definitions for these properties in both workspaces...). It is OK to replace all existing definitions because the library you would like to import has different name.


  • Re-create products in the base workspace. If the library name of the source workspace is originally different from the base workspace, we can import the products (Tools > Import > Products) from the source workspace. Otherwise, we need to re-create the products available in the source workspace - we should select the workspace having the least input variables as the base workspace! This is because we cannot duplicate a product for different library (even though both libraries are in the same workspace).
     
  • Add fields in model point files. If the variables from different libraries that used to read the same values have different names, I would suggest to include additional fields in the source workspace's model point fields - i.e. there are 2 or more fields having the same values in the model point files. When Prophet performs calculations for a particular product, it will ignore those fields which the field names are unavailable in the library that the product belongs to. By including these additional fields, we no longer need to prepare multiple sets of model point files.

Of course, we still need to perform necessary checking on the run results before we finalize the workspace for production - we may need to do additional modifications especially if the source workspace uses different definitions for the workspace level properties.

However, please note that the above proposal serves as short term solution only - we still need to do proper workspace consolidation in long run, otherwise it will require more efforts when we want to add new product into the workspace.

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