We’ve been shopping/comparing financial packages for about a year to replace MAS90. It comes down to Navision Financials and Sage Enterprise. We had references with horror stories for both products. Would someone shed some light as to your experience, and preferences regarding these products? … Some details: We’re a mid-sized electronics reservicing business with 600+ employees, 5 remote locations (currently using Citrix).
You say that - after one year - your two finalists are two products you only have heard horror-stories about? Is that a new kind of strategy?
Well, like any software, there are always horror stories. There is always the bias that one has for a particular software. I’ve learned a long time ago to weed through the disenchantment (and also the exaggerations of a particular software’s capabilities). Despite the horror stories of some individuals, the good features far outweigh the limitations of these 2 packages (Navision and Sage Enterprise) – if properly implemented in the beginning. These 2 packages would fit our needs more than the J.D Edwards, or the Oracles at the moment (and a “guessable” future, namely, 5-6 years). I’m merely soliciting this forum’s posters for some general opinions regarding the 2 packages.
Hi, I think the most value for client has the solution center experience. The top systems are very close in the functionality now. If you cant select between systems try to find the most experienced solution center in electronics reservicing business. I think it will be the best solution for you. Valentin Gvozdev BMI Inc.
You won’t find many people on this forum who can tell about Sage, I’m afraid. But if you want to know more about Navision, you are the right place. If your analysis has left you with questions on certain aspects, why not post these question here? I bet you will be surprised by the quality of the answers 
In general terms, Navision is powerful package for business wide automation. Our experience (as Navision Solution Centre in The Netherlands) is that nearly anything is possible with Navision. To give some examples: we integrated Navision with an Oracle based ordering system to get a smooth running stock control of the European Demo Depot of the largest company in internet equipment. For a world-wide operating company in the oil-business, we integrated Navision with Oracle, SAP and AS400 systems throughout the world. Let me assure you these companies also have done thorough checks and comparisons, and ended up at Navision for its completeness, flexibility and famous rock-steady reliable operation (Windows errors are hardly ever seen). But please do not overlook the required level of competence at the Navision Solution Centre you are dealing with. Don’t hesitate to ask the Navision office in your country if you are talking to the right NSC. It’s not unusual to talk with more than one NSC to see which one has the right kind of experience or competence for your business. Ask for references and do take the time to talk with companies where Navision is running. Don’t expect to get the absolute perfect system -that’s yet to be invented- but when properly tailored to your needs, Navision will get your business running in a short span of time - for a long period. John
I truly appreciate your responses. May I ask some pointed questions? 1)Would Navision slow down when our business grows to a point where we do 10,000 sales invoices per week? Along with 10,000 new sales orders a week? Speed is something I am very concerned with. 2)When transaction history keeps growing, does Navision slow down? 3)We’ll probably have 250 concurrent users on Navision SQL. Does anyone foresee a problem? Thanks for any reply. The local NSC already answered positively to these questions. However, I would like to hear from the day-to-day users of Navision. So far, I see a tremendous financial package that has plenty of speed, reliability and customizability. Am I off base?
- Don’t see particular problems for Navision at these volumes, but when such a workload is foreseen, you should be talking to some good hardware people as well. Make sure you will be running over a fast network, have thick servers with multiple harddisks (i.e. use the distributed services of SQL server) to get physically spreaded, simultaneous read/write operations. Have your servers loaded with plenty of RAM memory (1 GB) to make optimal use of caching. If modifications to standard Navision are required, make sure these changes are designed with a heavy load in mind (optimalization of keys, to name an aspect). 2) That depends on what information you want to retrieve from the transaction history. Extensive overviews will slow down, but for example the current outstanding balance for a customer is not influenced at all. You probably will have been told about the Flowfield technique and Sum Indexes of Navision, which gives all kinds of data back with a minimum of database activities. 3) If these 250 people are truly concurrent users, you are getting close to what’s specified as practical limit. However, to our experience the number of connected workstations and the number of real concurrent users are two different things. Even though there’s quite some data transferred over the network between server and workstations, the actual database load is mostly in short bursts. Also it makes quite some difference if the user is pumping out invoices, or occasionally looks up a price or so. You may consider to have i.e. invoicing done in automated batches which runs during the night. John
I can’t speak to all of the questions, but based on our experience handling extremely high volumes of sales and receiving transactions at the dearly departed Pets.com, here’s a couple of things to consider. 1. SQL posting is going to take significantly longer than the native Navision database. If the posting routine is standard Navision, depending upon the number of lines, it will generally take between 1 - 3 seconds per inovice with a heavy duty hardware configuration - this is with the Navision database. It will be approximately 25 - 50% slower with SQL in our experience. This translates into a lot of hours posting each day. 2. This process can be speeded up by modifications to the posting routine which would eliminate the multitude of transactions normally flowing to the G/L. Naturally, you give up something here as far as direct navigation goes. The same thing can be done in the inventory ledger. Basically, at Pets.com, we created a summary posting routine to these ledgers to maintain the speed. 3. If you need all this detail, you will probably be well advised to develop some type of data warehousing/archiving routine or process, because you will find the reporting will be affected, especially under SQL. The data associated with flowfields will also get slower over time. 4. With this volume of transactions/postings, you will absolutely need automated posting routines in place. Experience shows that this should not be done in a single batch, but under SQL, the postings can have a negative effect on the overall performance of the application. The operational needs of the organization need to be considered before implementing this type of process. 5. With postings this large, they need to be controlled, as access needs relative to the G/L during posting will be constrained under SQL. The converse is also true. Allen Beck President Beck Consulting Alameda, CA & Bellevue, WA allen@beckconsulting.com 800-456-8474
Thank all of you for replying. Please keep them coming.
Relative to my earlier comments, please keep in mind that all SQL products in this mid-range ERP category have some speed issues. Postings create a huge amount of record inserts, which in SQL 7 (and other SQL database products) can take a lot of time. Navision’s benchmarks and some of the literature relative to speed of competing products indicate that Navision’s design and use of the SQL 7 database cause it to be faster. When you’re looking at ERP applications, it’s important to keep in mind that the database back end has usually been attached through an evolutionary process. Two records of the same definition will be inserted slower on a slower system at the pure SQL command level. What’s key in the speed with ERP systems is how efficient and fast the program (not SQL)is. The beauty of Navision’s implementation of SQL 7 is that the really great data access, OLAP, and reporting capabilities in the native database are also in the SQL database. Unlike other products, there’s not different functionality between database types. In the long run, speed is going to be more of a hardware & infrastructure issue that can be easily addressed. However, the key is the organization you’re working with to make this a long term solution. Keep in mind that, unlike most of the other vendors, Navision Solution Centers must have proven competence and a track record before they can represent the product. Who you deal with is usually as important as the product you are considering. Allen Beck President Beck Consulting Alameda, CA & Bellevue, WA allen@beckconsulting.com 800-456-8474