These community forums are free for anyone to use, they provide support for OpenUnderwriter related matters. Please note, you must register with the website and login to post messages and questions, this helps reduce spam.
We've been looking at apt-get type tools to simplify the building of a development workstation on the windows environment:
First start a command line in administrator mode then run the command
- @powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\ProgramData\chocolatey\bin
This will install the chocolatey.org install tool
Close this command window
Open another (in admin mode) and run the following commands
- cinst java.jdk
- cinst eclipse-java-kepler
- cinst mysql
- cinst toad.mysql
You are now tooled up and ready to go.
Some optional recommendations are:
- cinst sublimetext3
- cinst googlechrome
- cinst opera
- cinst firefox
- cinst tortoiseSVN
You could imagine paying for your motor insurance with your petrol purchase.
Unleaded fully comprehensive petrol...
Reduce your premiums by driving slower and getting better efficiency. This may cause the interesting side-effect if the slower you drive the less likely you'll have an accident. See it can even create closed loops...
Working closely with an ex-Ilog consultant, who now is with IBM. I get a some good insight into what the IBM's stack includes and how they are pushing these solutions.
Of course the point here is that JRules is now a part of this stack and is a relatively cheap option for any current WebSphere user to add.
OpenQuote itself implements with Drools. I'm wondering how easily it is to "un-plug" to allow for other rete-based rules solutions and whether or not we should prove this ?
This reminds me of a chat we had one time or was it over email.
Like an extension to the collecting premiums from rent I mentioned previously. Surely there's a mobile company out there that would partner with an underwriter to offer say a "mobile phone theft policy" where premiums are collect from the mobile tariff. Then this could extend to more interesting forms of cover, "farmer labour's policy", "cattle disease cover" and so on. With each collecting premium from a mobile tariff, making it easier from the insured to get and pay for their cover, not to mention it being easier for the underwriter's and other intermediaries.
I think my point is that micro-insurance needs the various businesses to come together and not think in the traditional way of one organisation has control or owns the whole process.
Sharing out the risk of design, development, deployment and maintenance of insurance products should be a case of getting the right "things" together and letting them do what they do best. Not micro-managing and controlling the costs by getting cheap resource, or squeezing a 5 day task into 3.
If you want to cut costs. Start with the licenses, not the talent.
If you want to cut time. Start with the scope, not the talent.
As the solution we offer covers more and more of the insurance world the data we need to capture and persist will extend.
The various artefacts that we need to produce to support that will need to be addressed: screens, alerts, sub-processes etc. Should this not be the point at which we design a base template for a document?
Data mining is a future concern but are we sure we want to try and find a solution to something we haven't finalised yet?
If not shouldn't we be considering all the other items we haven't yet done?
Also, Data mining tools are not a documenting/reporting tool. This is a mistake many companies have made. Data mining universities are in fact used by reporting tools.
I agree Dick.
On a previous project some 10+ years ago the cover for household insurance was in the order of 1 or 2 GBP, this would be added to the cost of the tenant's rent.
Accurate and up to date bordereau was critical for this organisation for both earn/expected premium and paid/expected claims.
In the above instances the underwriting company had relationships with the various local councils (in the UK), who did the collections for them.
It's almost a supply chain issue, the whole process of designing, deploying, maintaining and operating has to be reduced. OQ gives the first 3, but insurance and underwriting companies need to make the relationships for the later.
The difficulty with Micro-Insurance will be in it's rush to create a saleable product with a minimum premium to the insured and risk to the insurer.
OpenQuote will help in this area due to it's Product, Section and Asset relationship. Where known quantites held as sections can be re-used with other sections to create ne products.
The emphasis for insurers then falls into the area of clarifying these sections and building up a library. These could be simple or difficult and wordy, where necessary. The overriding idea that each section should be an "atomic" bit of insurance that covers an asset.
Also, I think there is a desire to be able to push a proven Product fromone to another affinity group. For example, extending an Accident at Work Product for sheep farmers in Wales to an Accident at work product for wheat farmers in Egypt. There are lots of similarities in the assessment of the risk, production of wordings and validating of claims, one could see the larger challenge in the marketing of the product as well as how it is sold.
The more I read about micro insurance the more I come back to an old IT acronym 'KISS', keep it simple stupid. A large well organised library of sections and their assets that can be lifted to form new products in a design and test environment for the underwriter. A play/"what if" area no less!
OpenQuote has been design to this purpose from the ground up [the heart of OQ]
dickanderson wrote:OQ-110 Support Broker/Agent interactions
This doesn't yet define what interactions OQ should support, or how to support them. We'll need more detail before it can be put into a release.
dickanderson wrote:OQ-105 Improve business and developer documentation
This is am ongoing task, and doesn't belong in any particular release.
This is like unit-testing, should always be done. So, Agreed.
dickanderson wrote:OQ-153 Upgrade to latest release of JBoss server and Portal
As JBoss portal has changed radically (i.e. it has been replaced by GateIn), this doesn't feel like a point release updated. We should leave this for OQ2.0.
In some ways I'd like to separate Business and Technical requirements, can we divide the current requirements in those buckets?
Hence, as an example, we could say "with numbers and types of people available for this release, we can do the top ten from each bucket"...
Documentation comes is several shapes:
- Small Documents (1-10 pages): Certificates, Acknowledgements, Pamphlet, Quote document, Debit Note ...
- Large Documents (10+ pages): Policy wordings, Novels ...
- Data Mining: Reports
Each could easily have their own solution.
Small and large documents may have similar tools (e.g. BIRT) that can support multiple report solutions, although it is current a "fat-client" solution. But then I think all document output solutions are by nature.
When it comes to Data Mining though we need to be more careful in that we should try to ensure that we create a clear data universe, and how this can be configured, as opposed to a solution with one or other tool.
Tony this may be of interest http://msdn.microsoft.com/en-us/library … 11%29.aspx.
To be honest I haven't look at this in any detail, but it may give you some insight.
The wiki page for Doc Gen is "in progress".
But, just to give you a heads up. We are rendering our PDF documents using XSL:FO, we are using Apache's FOP processor to this end. As you may be aware FOP offers some other formats of documents as well as a plug-in for RTF. So room for future extensions there.
The extensible stylesheets are in the "themes" package of openQuote
Some updates are on the way. Which include the JIRA's Dick referred to previously (OQ-187, OQ-188, OQ-189, OQ-190).