Sage 100

SMI - Performance. I've been working with a couple of clients to setup financil statements using SMI. The chart of accounts are large for each client. Perhaps I'm doing something wrong, but to generate the data from MAS to Excel is taking over 10 minutes for a basic financial statement. Is anyone else playing with this and could comment on the performance issue?

Only ten minutes? Not bad. My one and only SMI guinea pig tester says it takes her about 30 minutes to pull the data.

There was at least one complaint on the community of northward of an hour.

Myron - can you define ""large

300 accounts. I don't think that's large, but for a mid-size business that's bigger than most. The larger issue for me is what will SMI do with dashboards connected to queries of AR history tables joined to other large tables. I have the uneasy feeling that this isn't going to work very well. Myron Stevenson Clearis Consulting, Inc. 1420 Morningside Ave Duluth, MN 55803 Voice: (218) 525-6720 Fax: (866) 550-9880 Mobile: (218) 391-5888 From: support@socialcast.com [mailto:support@socialcast.com] On Behalf Of Mike Fitzgerald Sent: Wednesday, March 23, 2011 4:22 PM To: Myron Stevenson Subject: Re: [90 Minds Consulting Group] SMI - Performance. I've been working with a couple of clients to setup financil statements using SMI. The chart of accounts are large for...

This whole speed issue is one reason that I'm hesitant to recommend SMI. What happens if we get elbows deep into this and the performance is terrible? Are we then obligated to spend unlimited time either fine tuning performance (Client: Yes) or do we wind up refunding all of our fees and probably any extra SMI licenses. I'm really waiting for one of you in the groups to provide a raving success story here before going much further with SMI.

And this is the main selling point of the in memory database of biznet

If I could get Biznet to donate a single user copy to one of you working on a sizable project to compare it to SMI and if you find it materially better, in return write up your results to the group, would you consider it?

IMHO, I think the death of SMi as a financial statement writer will be the speed not mentoning the complexity of making the fricking things

@markchinsky Just keep in mind that offer will likely involve a public post and if the findings don't go SMI's way then the author would probably have to defend the review to Sage. I don't think it's a bad idea but Biz Net is probably at risk of not getting a public post out of it (though if someone did this privately and posted that Biz Net blew SMI away it would probably prompt a few of us to adopt Biz Net. Just saying don't set an expectation with Biz Net that they will get an ""SMI sucks"" public post --- assuming that's even the result, etc.

Also, I think the way to sell this to BizNet is that we're probably not going to write up a big public campaign about the pitfalls of SMI -- at least not right away (unless you enjoy spending a day or two on the phone with Sage) however the way these apps become more common amongst 90 Minds members is we have good experiences and recommend them to each other (and those we know in the consulting community).

For the cost of giving away a copy (zero) for them to at least get the 25 of us to give it serious considering, may be reason enough to give it away. If it truly does blow away SMI (and I don't have the time, desire or energy to personally learn SMI for this) I'd be happy to get 'double banned' from going to Incites and would post it on my blog :-) I don't understand why everybody follows Sage like guppies. 98% of the employees have never been an end user or worked with end users or had to sell a product that they had to install and actually be responsible, physically face to face, for customer satisfaction and collections. Just because Sage does a search for the worlds cheapest FRx alternative or the one that will cut them in on the best deal doesn't necessarily mean the rest of us should build our business around it. Hell, its not even 'free.' The minute you want to do things the old 20 year old Custom Report Writer could do, you need to spend more money on SMI than Biznet is offering. Biznet charges Epicor users about $4k for what they are offering our clients at $897. How many times has Sage screwed us in this department in the past anyway?: EDI?, Time & Billing?, Timekeeper?, enhancements like Customer Last Purchase History?, MRP?, Starship? PC Charge?, Client Writeup?, Fixed Assets Module? F9? Faxmaster, Saleslogix (telling us to bet the farm on it and then switching to Sage CRM), Unix? And I'm probably missing 5 more of modules/products that Sage went 'all in on' practically forced us to sell and then dumped when they couldn't make enough money on it leaving our clients somewhat hosed and us in the middle

Oh and the first MAS200 SQL, Barcode Master (what a POS), oh and that reminds me, Point of Sale,

You veered off point a little here Mark -- my concern with SMI is how to answer the client ""Why should I pay when SMI is free"" --- I think that's a valid concern for small customers who ask to use what's free and may leave us vulnerable if the client uses SMI and find's it adequate after we've recommended against it. And with respect to going against Sage -- it's not jus them but most publishers that you write negative (or not glowing) posts about. I can name a dozen off the top of my head including registered letters from the service management people who weren't pleased that their product was described by multiple people as not ready. The problem is that unless you craft the post to be as bulletproof as possible most people shit their pants and take it down as soon as the PR folks call.

That's not a good sign re: SMI performance. The client I'm upgrading who had the FRx issues, etc., they had previously expressed interest in switching to SMI or some other financial reporting solution. ***The client's main company has 13,675 accounts!!!*** (that's not a typo)

I am beginning to wonder if the SMI ODBC connection suffers from the same issue that the Crystal connection does. I just assumed that since it was Excel based that the performance would be the same.

performance is definitely an issue. pretty much across the board. sat in a training session for the 500 version and the comments were the same.

If its slow in MAS500, than this problem is never going to be resolved. Biznet realized long ago the constant reconnect and re-extract to the database on a cell by cell basis is going to result in crappy performance. Does anybody know if SMI pulls all the transactions in or whether it depends on the pre-built buckets for the numbers? Because of the in-memory engine of Biznet, it works like Qlikview. This means you can run financials for any disparate set of dates, with or without month ends and get the same instant results as a monthly report. Sort of like the logic Dynamics NAV uses with their Sum Index Flow Tables(SIFT). @WayneSchulz To your point,: I would be happy to get on the Sage shit list and post it on my blog without mentioning any names if somebody doesn't want me to. I only want to post an honest comparison after somebody tries both in a real world scenario. I'd be happy to post nothing about it but rather keep the findings withing our group here and members can discuss it with peers as they see fit. Blocking customers from knowing the truth out of fear of Sage's PR department, IF SMI is a POS (and I have no idea if it is or isn't) isn't going to do us any good in the long run.

Ideally you'd run the SMI, FRx, and Biznet all on the same machine (only having one open at once) and compare speeds to see the difference.

Since SMI uses the SOTAMAS90 ODBC it suffers similar performance as other external applications. Just as DSD's mirror and other MS Access performance solutions speed up Crystal Reports, they can be used to speed up SMI. SMI directly injects a SQL query result set into thier impressive spreadsheets. By duplicating the query in SQL or MS Access, the injected worksheet can be replaced by a MS Query result set from the same data in SQL or MS Access (including pass through queries).

From day one of this SMI announcement my opinion was that we should wait and see what the performance issues might be. The ODBC and Excel back end are red flags to potential performance issues. As I've mentioned before - Excel is a blessing and a curse. Power users love it because they'll tailor it to how they want to see the reports. That's great. Unfortunately since there's no standardization you have to deal with Franken-spreadsheets in a year or two when PowerUser leaves the company. That's what was beautiful about FRX - the structure was standard and you could understand the layout within 30 minutes. I bet with SMI if you were to visit an orphan (with extensive use) more often than not you'd be proposing to completely re-write the SMI reports. Remember the typical customer who asks about SMI has: a. Gotten a notice that it's a free tool b. Wants to know if they can install it themselves c. Wants to duplicate FRX functionality d. Assumes (not unreasonably) that FRX will be converted e. Figures they'll have to pay you $100 or so just to throw it on a computer Take the bait on any of the above and I believe you'll be faced with a few choices: 1. Eat the time 2. Lose the client This is a hairy area because to give the client a full picture of SMI means you go against the Sage recommended product by giving the pros and cons (sounds like mostly cons).

@DanBurleson - Any idea why SMI crawls through the ODBC connection? This is the same connection that flies with an Excel Query.

I would guess it is because of the complexity of their queries. They involve a lot of tables and joins.

The queries are probably not optimized. Myron Stevenson Clearis Consulting, Inc. Voice: 218.525.6720 Mobile: 218.391.5888 Fax: 866.550.9880

I think Denise pointed out the problem during the discussion around their Biznet solution. SMI, queries the database separately for each cell. This is what allows it to show say 3/1-3/15 data in one cell and 3/16-3/31 data in another. It does not have its own on-board data warehouse to do this. This would also explain why its even slow on SQL which we know is normally darn fast with Crystal which does one call into an internal database (which can be refreshed manually when you hit the lightening rod icon). The answer is one of us who has a client with a need and who already knows SMI, needs to take Biznet for a spin (I guarantee I can get a free copy or trial copy for this situation) and compare the results against a similar database. This needs to be done sooner rather than later as clients are going to be asking more and more as the fact that FRx is no more becomes more apparent to them. If you don't want to invest the time, if you can convince the client to allow biznet to take a copy of their database and they create the report and show us, that could work as well. The databases have to be identical for the comparison to be meaningful. Don't forget I recorded this demonstration to the group. Now what isn't fair about this is that its talking to MAS500 in this example instead of MAS90. http://www.youtube.com/watch?v=jeiRDkvc050

Remember, if you can build and see your results virtually instantly compared to 10 minute runs, than any savings your client might get by having a 'free' copy of SMI will get quickly eaten up watching you play with your phone while waiting for reports to process as you are testing.

@MarkChinsky SMI does not query separately for each cell. It injects a table into a hidden worksheet that is the result set of a single complex query against SOTAMAS90. A visible worksheet then presents the data from the injected table in a summary layout. By replacing the table in the hidden worksheet, one can eliminate the dependancy on SMI components after the report has been designed. That means also eliminating the extra license requirement for scheduling updates.

Well that's good to know. But why is MAS500 slow then when SQL queries are so darn fast? Your workaround should work but I don't want to implement a solution that requires a workaround for acceptable performance in 2011.

Crazy, we are already building workarounds for a solution that Sage picked as the best replacement for FRx.

@MikeFitzgerald Are you hearing any comments from your counterparts at Net@Work on SMI?

Looks like Sage did their usual deep due diligence on SMI before choosing/releasing it...'How much commission you willing to give us?' If they hear an answer they like, they go with it. http://community.sagemas.com/t5/Sage-MAS-Intelligence/Solutions-on-SMI-Slow-Performance-Issue/td-p/45892 From the very small amount of traffic on the Sagemas community, it tells me very few people have actually used this yet.

Not there yet, but we are pretty actively looking at Biznet as an alternative for our customers who don't like the looks of SMI. We had one customer look at SMI and they came to us and asked what else we had. We showed them Biznet and their comparison was ""SMI looked like it would take days to learn while they felt like they could start using Biznet as soon as the demo was over"". Quote is out with this customer and we are reviewing Partner agreement with Biznet. Obvious hurdle is that SMI is free, while Biznet is not. And while we can all make a passionate case for ""total cost"" of a simpler solution they have to pay for is less than the free solution, it is still a free solution.

We have one customer using SMI so far. I'm not sure what they think of it.

can you reach out to them and see? Do you know how big their GL is in terms of both GL accounts and approximate transaction volumes?

Ok, Just spoke with Denise. They are going to dig up a larger MAS90 data file and do another demo for us to illustrate the performance of the app. If anybody has a creative layout they would like to see that seems hard to do in SMI, let me know and they will do it. I'll let everybody know when I try and get some dates for a gotomeeting. (Which I'll record again)

I've seen a couple of mentions in this thread about SMI being ""free"". Anyone used to using FRx is going to need the Report Designer at a minimum and will probably need the connector unless they are going to have the reseller create the reports. If they don't get the connector and want to import the report created by the reseller, which includes a custom connection, they'll need a second report manager.

So how much are a talking?