What's the latest verdict on TAMonline?

Started by Lance Weaver, December 06, 2012, 12:55:04 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Mark

Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

Jim Jensen

Quote from: Mark on December 11, 2012, 03:16:20 PM
Epic is NOT web based.

True and thanks for clarifying my poorly worded response. My thought was simply because of when it was developed and with the clear intent of the online hosting from beginning, it *may* have better workflows than TAM. I haven't seen it so I can't say that it does, but no mention of it at all, I thought it good to bring into the conversation, at least for consideration if someone is thinking of moving from LAN to online anyway.
Jim Jensen
CIC, CEO, CIO, COO, CFO, Producer, CSR, Claims Handler, janitor....whatever else.
Jensen Ford Insurance
Indianapolis

Mark

Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

GeorgeW

We are Epic Lan based. From a hardware standpoint, I'd think you'd save quite a bit of money going On-line. Of course, we are probably larger than most, but hardware costs alone are huge!
George Watson
AssuredPartners NL, Louisville, KY
Epic 2022 R2, MU2

Alice Mooney

Regarding scanning/attaching large items, would that affect bandwidth and slow others down?  Like if I scanned a 7MB commercial doc, and attached it during busness hours, would that not affect useage and slow Tam down for others?  Unless there's a way to schedule the upload/attaching after hours so it won't affect anyone.
Something I just thought about regarding the road we are going down...
Epic 2023 R2 Online
1000+ users

Mark

Quote from: Alice on December 11, 2012, 04:27:50 PM
Regarding scanning/attaching large items, would that affect bandwidth and slow others down?  Like if I scanned a 7MB commercial doc, and attached it during busness hours, would that not affect useage and slow Tam down for others?  Unless there's a way to schedule the upload/attaching after hours so it won't affect anyone.
Something I just thought about regarding the road we are going down...

I'm going to just throw out a "yes" right away without even thinking about it.   :)
Mark Piontek, MBA
Director of Information Systems
BS in Information Systems Security

brinkerdana

Quote from: Mark on December 11, 2012, 04:59:05 PM
Quote from: Alice on December 11, 2012, 04:27:50 PM
Regarding scanning/attaching large items, would that affect bandwidth and slow others down?  Like if I scanned a 7MB commercial doc, and attached it during busness hours, would that not affect useage and slow Tam down for others?  Unless there's a way to schedule the upload/attaching after hours so it won't affect anyone.
Something I just thought about regarding the road we are going down...

I'm going to just throw out a "yes" right away without even thinking about it.   :)

Has not been my experience.   We scan large policies all the time and don't experience any slow-down.
Dana Brinkerhoff
Retired

Jeff Zylstra

I seem to remember some kind of utility that scans the items locally, then forwards them to the remote server after hours when traffic isn't so high.  Is that part of TAM Online, or was that some other remote scanning utility that I am remembering?  I would think that a large file would negatively affect internet speeds unless you had bandwidth to burn, or were using a separate internet connection.
"We hang the petty thieves, and appoint the great ones to public office"  -  Aesop

GeorgeW

You are able to scan directly into TAMonline. They used to have an upload center to upload documents to TAMOnline and that would send smaller files immediately and larger files overnight. Our TAMOnline agency users at the time always just emailed themself the attachments and then attached instead of using the upload center.

(BTW, I hated TAMOnline)   ;D
George Watson
AssuredPartners NL, Louisville, KY
Epic 2022 R2, MU2

Conan_Ward

jeff, you're probably thinking of the old upload center, which works as George stated, the program for scanning can scan directly in (once you start the scan process from TAM). Thankfully the newer upload center just does everything right away and without using the portal to make things easier once its installed...at least to me, it seems to be more user friendly like that.

I think part of TOL to a lot of people, to have it work well is mostly having the bandwidth to burn since all your work is based around your connection. Those who don't decide to make sure they have enough to go around or add users faster than they add bandwith (or just one person who likes to use pandora at their desk) tend to not enjoy the environment as much.

Most of what i'd say for/against has already been covered, plus I think my opinion would need to be slightly biased anyway ;)
Former TAM support, P&C licensed in Maryland, LFW

Ben Thoele

Quote from: Lance Weaver on December 11, 2012, 02:39:22 PM
The reason for interest is that some principals here are 1.) interested in the disaster recovery benefits of having TAM hosted elsewhere and 2.) believe that it will be easier on IT (me) and 3.) believe that if I get hit by a bus, no one else can take care of TAM.

Another driving factor is that we've been using the web-based BenefitPoint system for some time now and our people love it.  We have very few problems with it and it's rarely down so we are saying "what if we could do this with TAM too...?"  The problem that I see is that it's not an apples-to-apples comparison as we went from having a very weak benefits management system (TAM) to Benefitpoint, a true browser-accessible web-based app, so of course they love it.  The TAM in-house to TAM-online comparison is a little different as, as far as I know, TAMonline is really still just a TS environment.  So it's for us, it's not really a good comparison to think "because we love Benefitpoint" then "of course we'll love TAMonline too".  My fear is that, due to moving TAM into the TS environment, workflows will get more complicated and slower, general overall performance will be slower due to Internet link, dependancy on Inet link now becomes an achiles heel (over the last ten years, we've had many more issues with our Internet connectivity, than we've had disasters that take down our systems).

It's a tough call.

We have a new vendor in central Minnesota that's filling a gap in the "cloud" IT space.  Until now your two choices in most areas were either to host all your own stuff or outsource to an ASP.  In the ASP model cost goes way up and control goes way down.  If your agency has good IT staff then the only problem with hosting your own is the DR question. What happens if the building and it's contents are gone. The new hybrid model is the best of both worlds. http://www.vaultas.com/ Vaultas You still leverage your office as a backup target and then you move your datacenter, one server or ten to a dedicated data center.  A vendor neutral data center!  I repeat, a vendor neutral data.  You still buy all your stuff using the best partners like a Quick lease from Dell and you host it from a climate controlled building. 

The partner we talked to sets many of their customers up with 100Mb or 1Gb internet.  If your Internet gets cut you fail back to your backups,  something you can't do with an ASP.

Check out is model, it maybe an option for you.
Ben Thoele, I.T. Coordinator
TAM 12.2
33 Users
Mahowald Insurance
Saint Cloud, MN

Billy Welsh

We are doing something similar - but the independent data center is for the DR copies.  Our contract IT firm has the hardware in the data center, and essentially rents us virtual servers and offsite backup storage.  In the event of a disaster or evacuation, the backup servers are put on-line and the most recent data is restored.  At that point all you need is an internet connection, the correct ip address, and the term server client.

Being a small shop in a hurricane area, this is a nice solution for us.  No need to train the whole staff on Term Server unless and until we have to use the DR site.
Billy Welsh
Director of Accounting
LCMC Health

Hans Manhave

This would mean that you have all remote offices, possibly with one "local" station at the colocating/hosting site?  With everything online, it would be debateble if rented office space at a datacenter is any different than rented office space across the street.  I guess no workstation needs to be hardwired to the server, but what is hardwired anyway?  There are always switches to go through and adding one or ten more switches really doesn't change anything when considering if something is connected or not.

Interesting thought.


Quote from: Ben Thoele on December 18, 2012, 04:37:10 PM
Quote from: Lance Weaver on December 11, 2012, 02:39:22 PM
The reason for interest is that some principals here are 1.) interested in the disaster recovery benefits of having TAM hosted elsewhere and 2.) believe that it will be easier on IT (me) and 3.) believe that if I get hit by a bus, no one else can take care of TAM.

Another driving factor is that we've been using the web-based BenefitPoint system for some time now and our people love it.  We have very few problems with it and it's rarely down so we are saying "what if we could do this with TAM too...?"  The problem that I see is that it's not an apples-to-apples comparison as we went from having a very weak benefits management system (TAM) to Benefitpoint, a true browser-accessible web-based app, so of course they love it.  The TAM in-house to TAM-online comparison is a little different as, as far as I know, TAMonline is really still just a TS environment.  So it's for us, it's not really a good comparison to think "because we love Benefitpoint" then "of course we'll love TAMonline too".  My fear is that, due to moving TAM into the TS environment, workflows will get more complicated and slower, general overall performance will be slower due to Internet link, dependancy on Inet link now becomes an achiles heel (over the last ten years, we've had many more issues with our Internet connectivity, than we've had disasters that take down our systems).

It's a tough call.

We have a new vendor in central Minnesota that's filling a gap in the "cloud" IT space.  Until now your two choices in most areas were either to host all your own stuff or outsource to an ASP.  In the ASP model cost goes way up and control goes way down.  If your agency has good IT staff then the only problem with hosting your own is the DR question. What happens if the building and it's contents are gone. The new hybrid model is the best of both worlds. http://www.vaultas.com/ Vaultas You still leverage your office as a backup target and then you move your datacenter, one server or ten to a dedicated data center.  A vendor neutral data center!  I repeat, a vendor neutral data.  You still buy all your stuff using the best partners like a Quick lease from Dell and you host it from a climate controlled building. 

The partner we talked to sets many of their customers up with 100Mb or 1Gb internet.  If your Internet gets cut you fail back to your backups,  something you can't do with an ASP.

Check out is model, it maybe an option for you.
Fantasy is more important than knowledge, because knowledge has its boundaries - Albert Einstein

Jeff Golas

#28
Quote from: GeorgeW on December 11, 2012, 03:55:42 PM
We are Epic Lan based. From a hardware standpoint, I'd think you'd save quite a bit of money going On-line. Of course, we are probably larger than most, but hardware costs alone are huge!

Just looked at your sig and I'm curious how this lays out? Do you have a central office or multiple servers replicating? Why did you guys choose to keep it in house and take on that hardware cost vs just having Applied host it?

In my opinion, other than SAN storage, hardware/servers/network is a LOT cheaper in terms of what you get for the dollar these days. Its the software licensing (SQL) that kills you.

(BTW I still prefer in house for some things, and hosted for others...there's so much available to you now on an IT level, and in some cases running it yourself does keep some control in your hands).
Jeff Golas
Johnson, Kendall & Johnson, Inc. :: Newtown, PA
Epic Online w/CSR24
http://www.jkj.com

GeorgeW

I can't give you the details you are wanting most likely as I'm a lowly helpdesk tech. :)  We have one huge Epic database for all of our offices with all the hardware here in the home office. Each office has their own local file server for shared files, etc.  Not sure but there are a number of servers involved for just Epic. I believe the main reason to not go on-line is they wanted to be in total control of the data. We had used TAMOnline for one of our smaller agencies for awhile and were happy to move away from that. If you wanted to talk to someone about the specifics of our setup, I'm sure I could arrange that. I believe we may be one of the largest LAN based Epic's around right now. Applied was very involved in helping configure our setups so things would work.

A smaller agency should probably not even consider lan based and just go with on-line. Larger agencies would need to weigh all the costs and manpower involved in hosting locally.

Sure this didn't help much!  :o

Quote from: Jeff Golas on December 19, 2012, 05:06:50 PM
Quote from: GeorgeW on December 11, 2012, 03:55:42 PM
We are Epic Lan based. From a hardware standpoint, I'd think you'd save quite a bit of money going On-line. Of course, we are probably larger than most, but hardware costs alone are huge!

Just looked at your sig and I'm curious how this lays out? Do you have a central office or multiple servers replicating? Why did you guys choose to keep it in house and take on that hardware cost vs just having Applied host it?

In my opinion, other than SAN storage, hardware/servers/network is a LOT cheaper in terms of what you get for the dollar these days. Its the software licensing (SQL) that kills you.

(BTW I still prefer in house for some things, and hosted for others...there's so much available to you now on an IT level, and in some cases running it yourself does keep some control in your hands).
George Watson
AssuredPartners NL, Louisville, KY
Epic 2022 R2, MU2