Phoenix Users Group Regional Executive Strategy Session

1
Phoenix Users GroupRegional Executive Strategy
Session

• Agency Insurance Co
• Linthicum, MD
• January 13, 2009

2
Agenda

• Where weve been
• Where we are going
• PremiumBill
• Portal Server
• Phoenix 9 Beyond
• Services Offerings
• Thoughts on collaboration

3
Phoenix 7.x and Prior Whats wrong with this
picture?

• One answer not much. It gets the job done.
• Another answer see PUG top 10 list

• Thick client
• Not built with flexible integration in mind
• Not familiar to upcoming generation of users
• Difficult for us to support
• Difficult for us to sell

4
Where are we going?

• N-tier .NET architecture
• Web-based UIs
• Emphasis on XML web services
• SOA approach
• Suite of applications which may or may not be
  used together
• Touch-only-on-exception model
• True to the configurable Phoenix philosophy

5
Future Architecture
Security
Authentication
Authorization
Core Services
Output
Rating
Rules
Workflow
Messaging
Schema-based data access
Directory Services
6
Future Architecture
Security
Authentication
Authorization
Example Policy admin only customer
Core Services
Output
Rating
Rules
Workflow
Messaging
Schema-based data access
Directory Services
7
Future Architecture
Security
Authentication
Authorization
Example PremiumBill customer using other
solutions for policy administration, etc.
Core Services
Output
Rules
Workflow
Messaging
Schema-based data access
Directory Services
8
How are we getting there?

• Billing has already made the leap PremiumBill
• Agent access in flight right now Portal Server
• Core policy administration comes next Phoenix 9

9
(No Transcript)
10
Complete web-based, n-tier .NET billing
solutionBill Screen Shot
11
Architecting the Future
12
Moving the Back Office Forward

• Times have changed
• Billing is now a service and marketing tool
• E-business pressures
• Carrier challenges mount
• System complexity
• Competitive Disadvantages
• A new billing model was needed
• Breaks the ties to Phoenix
• A new approach

13
Balancing Carriers Needs

• Technology Needs
• Single billing system
• Multiple policy system integration
• Latest .NET technology,
• Service oriented architecture, Web Services
• XML Output
• Business Needs
• User-friendly, consumer-driven design
• Easily reschedule pay plans
• EFT and payment imports
• Configurable and flexible rules and payment
  plans
• Suspend billing
• Split bill, upcoming account/client-centric
  billing

14
Roadmap

• Strategic Intent
• Support needs of broader carrier market
• Features
• Accept Credit Card Payments
• Account/Client-Centric Billing
• Commission disbursement
• Improved payment posting automation
• Support for AMS Portal Server billing inquiry

• In Planning Stage
• Connec to agents customers
• What were considering
• Account current
• Direct bill commission statement download (incl.
  comm. on paid)
• Select installment schedule based on payment
  amount
• EBPP for policy holders
• EBPP for agents
• Payroll deduction
• Note current release supports e-delivery of
  bills notices

15
The Future of Billing

• The move has started
• 3 Clients in production
• Commercial Property /Agency Bill
• Personal Package/Direct Bill
• Commercial Lines/Both Direct and Agency
  Bill/Phoenix and Non
• 1 New client signed in January
• Personal and Commercial/Direct and Agency Bill
• We want to keep the momentum going
• Attractive deals for early adopters
• Phoenix billing to PremiumBill migration tools
• Lets talk about how we can address your billing
  needs

16
(No Transcript)
17
What is Portal Server?

• Next-generation web-based agent access
• Takes tool-based Phoenix philosophy to next level
• Works with new or existing agent portals
• Web-based real-time rating, using your existing
  rating logic
• Integrates with Agency Management Systems for
  Upload
• Not tied to Phoenix will support other back-end
  systems
• Release 1 - available early 2009 Phoenix
  inquiry quote

18
Technology

• Tied to XML schema not the Phoenix DB
• Web services provide data access
• Microsoft Workflow Foundation (WF)
• Flows
• Activities
• Call-outs for third-party data feeds
• Claims-based Federated Security (Geneva)
• Configurable design plug and play

19
Three steps to get Phoenix into your portal
?
Step 2 Design-time create mark-up Templates
Step 1During buildout generate schema for line
of business
Step 3 At run-time Portal engine returns html to
portal.
20
Phoenix Web Services Portal Engine
FIREWALL
App Server
Schema
Web Pages
Web Server
Templates
Phoenix
Contact /Quote
LOB Developer or Business Analyst
Web/IT Developer
21
Components

• Portal Studio Toolset for generating schema and
  creating templates
• Portal Framework Out-of-the-box portal, for
  those clients without existing agent portals
• Portal Engine Run-time engine that returns HTML
  mark-up for templates and flows
• Contact/Quote Database, Agency Isolation,
  Claims-based Federated Authentication

22
Template Designer
23
Workflow
24
Benefits

• Speed to market
• Rather than buy or build buy so you can build
  better
• Leverages existing investment (rating logic and
  Phoenix build-out)
• Real-time and upload
• Works with more than just Phoenix
• Integrates to your existing portal look and feel
• Does not pigeon-hole you into our solution
  mark-up integrates with your web code
• Puts the right tools in the hands of your staff

25
Q But I already have an Agent Portal
why should I care about Portal
Server?

• Portal Server returns HTML mark-up for your line
  of business build-outs, which can be integrated
  into your existing agent portal, with its
  existing look and feel/branding.
• We do the hard part for you creating, managing,
  and maintaining the mapping to your back-end
  systems.
• How is your current portal working for you? How
  quickly can you roll out new lines of business?
  How quickly can you expose changes to your
  back-end configuration?

26
Roadmap

• Strategic Intent
• Agent channel integration
• Support non-Phoenix policy systems
• Major Features
• Support for non-Phoenix XML schema generation
• ACORD XML integration (upload, comp raters, real
  time)
• Mid-term changes renewals
• Agent-Underwriter workflow enhancements
• Enhancement of tool set responding to the user
  community

27
Call to Action!

• Take the message back to your company
• Interested in seeing Portal Server work with your
  database and lines of business? Ask Mary Ann
  Emmert!
• Stay tuned for upcoming WebEx demonstrating
  workflow February
• White paper and video demos available on AMS
  Carrier Community Site (http//www.amscarriercommu
  nity.com)
• Help us prioritize Release 2 and beyond features

28
(No Transcript)
29
Phoenix 9

• Long-Term Vision
• Define. Manage. Profit.
• Define
• Insurance products, business rules, workflows.
• Manage
• Book of business, product definitions,
  processing.
• Profit
• Realized through efficiency effectiveness.

30
Phoenix 9

• Begin replacement of Policy Entry, Policy
  Manager, Desktop, etc. with web UI
• Expect incremental delivery of web functions,
  minimal work on older Centura/C
• Focus is in-house carrier staff, not agents
• Leverages.NET components developed for
  PremiumBill Portal Server where applicable

31
Roadmap

• Strategic Intent
• Deliver Phoenix functionality via thin client
• Features
• Web access to Phoenix
• Inquiry
• Quote/Issue
• Mid-term change and endorsement
• Security
• Support for Single Sign On
• A common authentication mechanism for Phoenix and
  PremiumBill
• A common role-based access mechanism for Phoenix
  and PremiumBill
• Retire older Phoenix applications
• ISO templated LOBs

• Strategic Intent
• Additional thin-client functionality, eventual
  retirement of Policy Entry Policy Manager
• Features
• Renewal/Cancel/Reinstate
• Updated Output Solution(s)
• Access to multiple Rating Engines (ART, .NET, 3rd
  party)
• Phoenix Studio toolset to manipulate new
  insurance product definitions
• Continued roll-out of ISO templated LOBs

32
Phoenix 9
33
Phoenix 9
34
2009

• Concentrate on adding business capability to
  Phoenix Web Services and designing developing
  the initial web-based UI.
• Incremental releases
• Web Services 3.5
• Web Services 4.0 and Phoenix 9.0
• Web Services 4.1 and Phoenix 9.1

35
Phoenix 9

• Phoenix Web Services 3.5
• Objective Add to existing web services, adding
  to the foundation of business processing.
• Subset rating
• PME Support
• Policy Issuance
• Critical fixes

36
Phoenix 9

• Phoenix Web Services 4.0 Phoenix v 9.0
• Objective Continue to build out essential
  business capability introduce initial Phoenix
  Thin Client
• Policy Client Search
• Business UI
• Phoenix Thin Client UI
• Common point of transaction initiation
• Workflow support
• Leverage Portal Server work
• Re-factored sample/test application

37
Phoenix 9

• Phoenix v9.1
• Objective Introduce advanced back-end
  processing, providing high throughput and
  unattended operations.
• Renewals processing
• Web services as required

38
Phoenix 9

• Planning
• Rules Engine
• ART replacement
• Intermediate step parser/interpreter (run-time
  optimization)
• DocPrint replacement
• Reporting database

39
Phoenix 9

• Key Questions
• How should our priorities be adjusted?
• What types of transactions are occupying the most
  people-time, needing automation or improvement?
• Are there key activities that are growing in
  importance that Phoenix lacks?
• What are your biggest desires and expectations of
  a next-generation policy administration system?
• Do you have a vision for the future state of
  insurance processing within your organization
  that you can share?
• Are there infrastructure upgrades planned in your
  organization that will affect your Phoenix
  implementation?

40

• Professional Service Offerings
• Line of Business Build Outs
• Staff Augmentation
• XML Mapping
• Product Training
• Hosting
• Web Service Installs

41

• Professional Service Offerings (cont.)
• Web Service Training
• Migration Assistance
• Custom Development
• PremiumBill Implementations
• Portal Server Implementations

42
The Future

• Move to modern policy system incrementally with
  AMS no forklifts
• Modular approach makes us more competitive more
  ways to bring new customers into the fold
• Imperative and in progress this is not a trial
  balloon!

43
We Need Your Input!

• An Active Partnership
• Strategic guidance
• Tactical input during development cycles
• Real world perspectives from real world users

44
Collaboration Opportunities

• Steering Committee
• Collaborate with AMS to establish priorities and
  periodically review strategic progress
• Goal is to drive product direction to provide the
  greatest strategic value
• Need those responsible for or influencers of
  build/buy/replace decisions
• Meet relatively infrequently (quarterly or less)
• Stable consistent participation over time

45
Collaboration Opportunities

• Customer Teams
• Collaborate directly with product teams, ensuring
  that features are built correctly
• Need those who understand the specific business
  needs and can articulate those needs
• Involvement may be frequent, intense (1 hr/wk or
  more) during certain points
• May change based on what is being built

46
Collaboration Opportunities

• Thoughts on mechanics infrastructure
• Goal is to provide transparency enable
  participation
• Re-work AMS Carrier Community Site
• Idea submission/voting
• Top 10 Product Priorities
• High-level iteration objectives
• Articles. White papers, presentations related to
  product direction
• Discussion forums product direction and
  priorities
• Wiki for customer team collaboration
• Quarterly webinars
• Conference calls
• How do you want to communicate with us?

47
Lets work together!