General Consultant Discussion

Has this group developed a list of reasons / justification for upgrading an ERP system? I have a meeting tomorrow and the client is asking for cost justification and good business reason they should spend the money to upgrade from 4.4 to 2013. Looking for some ammunition. I am currently developing the list of enhancements, but I don't believe the enhancements alone will be sufficient to persuade them.

Send the prerelease docs. Compatibility to windows 8 etc

Are there any actual reasons other than dodging planned obsolescence?

IT wants to move to the SQL version (premium) for all the good reasons.

That is a good reason.

Finally a customer asking the right question. Add your labor costs plus 21% annual maintenance for 2 years (time between those versions) and then try and justify the difference from 4.4 to 2013. Good luck with that...

@MarkChinsky - I have no problem pricing... after all I just attended the MOTF symposium. :-) The issue I have is determining value, which of course requires a lot of thought and can be difficult.

Single version upgrade (ie 4.5 to 2013) I'm starting at $3,500 for random web inquiries - less for customers if I've done the upgrade before and it's vanilla. I believe that we also have to take into consideration competition - mostly because I see people every day emailing me to compare a price that they've received from their existing partner.

I think my point is not about what you should charge for the service, but more, the lack of material value a customer gets for spending 21%/year on maintenance and whatever you charge for the upgrade services... Other than sage praying a new Microsoft OS breaks something, what will work better in their business to justify what probably averages $1,000/month in maintenance and upgrade services.

You've just uncovered one of the downsides to on-premises solutions (the need for manual upgrade).

Overcoming the paltry benefits of the enhancements is tough unless the customer is fortunate enough to find one or more that solve a problem. We have always espoused the 3C's of ERP software: Be Current, Compatible, and Compliant. Current - you pay for them, so install them and you just may use more than you think. Incremental steps are more likely to take hold than infrequent large leaps. Compatible - you're probably updating all your other software, many that may interact with ERP. Compliant - ensure good performance and guarantee Sage support by compliance with Supported Platform Matrix. Unfortunately, Sage Business Care has become viewed as more of a mandated insurance policy than a preferential investment. Fixed fee upgrades with SOWs seem to be making it more palatible.

Whether the ERP software runs on an X86 processor in my office, or on an X86 processor in some data center is decoupled with whether software upgrades or not. NetSuite might not charge you for upgrade services, but they are charging vastly more per year, over a 10 year period than Sage does including the 21% maintenance and our bill to do the upgrades. They just build their R&D and upgrade efforts into their monthly price. If their software truly 'auto upgrades' is debatable. Usually if it does its' because you can't do any significant customization beyond some UDF's and workflows. If they allowed you to do real customizations, then when they modify their schema's it would break pre-existing reports and schema's. For example, if they enhance their UOM functionality, that breaks alot of custom reports that make certain assumptions. How much upgrade work is involved in upgrading quickbooks for example since it doens't allow real customization? If a customer does no customization to MAS, has no custom reports and upgrades on every release (similar conditions to most saas solutions), then it's pretty much a 'file/run/setup' operation as well.

@BobPfahnl - I like your 3C's... they communicate value for the investment. I will add a 4th C to the proposal: Competition - current ERP technology allows for better processes, efficiencies, and customer service.... a competitive advantage.

@DougHiggs , That's all true and all but what competitive advantage does customer get in 2013 from 4.5?

@MarkChinsky - The reason I started this thread was to get ideas of the value of an upgrade and what others have used to gauge this value. I have a few ideas, and others in this group have many others. Having just attended the MOTF symposium I am trying to learn as much as possible about determining value... I am learning (slowly). I'm not trying to debate the justification of upgrading. I particularly liked the advice offered by @BobPfahnl. The customer I have created a proposal for is potentially moving from 4.4.3 Advanced to 2013 Premium. The competitive advantage is that once upgraded, my client will have an ERP system with features its competitors do not have (if the competitor does not also keep current). The resulting current ERP system will allow for better processes, efficiencies, and customer service, .... a competitive advantage. Particularly, expanded AP invoice #s, inactive vendors, viewing cleared checks in vendor maintenance, processing credit cards in cash receipts and invoice entry, ability to inactivate customers, integrate multiple companies with SageCRM, use of TLS authentication in SMTP (Exchange 365 compatibility), and visual process flows. These new features should improve processes, efficiencies, and customer service.... a competitive advantage. In addition to the 20 page laundry list of Sage ERP enhancements since 4.4.3 there are SQL server advantages. Specifically, the advantages of moving to SQL include: High Speed: SQL Queries can be used to retrieve large amounts of records from a database quickly and efficiently. Well Defined Standards Exist: SQL databases use long-established standard, which is being adopted by ANSI & ISO. Non-SQL databases do not adhere to any clear standard. No Coding Required: Using standard SQL it is easier to manage database systems without having to write substantial amount of code. Emergence of ORDBMS: Previously SQL databases were synonymous with relational database. With the emergence of Object Oriented DBMS, object storage capabilities are extended to relational databases. Stored procedures: These are lines of code, pre-compiled and placed on servers for quicker response time. This centralizes code so changes made at a single point get updated everywhere else; a big respite from the inline SQL commands. Scalability: While a database such as MS Access can choke under huge volumes, MS SQL with all its features can not only handle the volume with efficiency, but can be scaled up to be better equipped for higher volume. Security: MS SQL gives power to the administrators. Administrators can give access to users even down to the table or row level. A huge advantage for databases where a lot of business critical information resides. Transaction Logs: MS SQL records transactions and lets you roll back to a previous version. This helps in case of wrong updates or data related accidents. If the competition doesn't have these features / processes, it is a competitive advantage.

Doug, I try to focus on the business-level problems that the features solve. All the details about the advantage of SQL are fine, but why does a CEO care? What db integrations become easier and more robust because of it, and what some sense of $$ at risk with that? What sort of reports will we be able to do with SQL that we can't or are very hard now? What ""costs"" have we been enduring because we have limited AP Invoice numbers, etc. The tech feeds and speeds that support those go further back in the proposal; keep the business performance goals up hight. When you structure proposals like this, you get more attention from top level folks. It can even stimulate them to ask, ""If we can get that, then does it mean that we will also be able to X?"" Your answer then can be, ""No, but if we also do Y, then X is possible. Why do you want X? How much $$ is at stake with doing X well?

@JerryNorman - Thanks Jerry. That is terrific advice. I need to drill down further and apply the features to issues particular to each customer. Obviously, this approach requires a lot of in-depth analysis, but the result is the value statement which (hopefully) make the project worth while for everyone.

Doug, this is the really, really hard part of Pricing on Purpose. It is where we tease out from the customer what is valued and why. And we can then gain more of their trust about our advice, and go from there. I'm not as good at this as I'd like to be. But practice makes ... better.

Doug, most of your 'sql advantages' look like a copy & paste from some blog. Most of them, don't apply to the 'lazy' way Sage implemented SQL for MAS. For example, when that client pulls the plug out of the server during AP invoice posting and you told them it had 'transaction rollback' and they have all sorts of half posted dated because Sage mostly uses sql as a 'plugin' instead of storing data in providex files, they might hold you liable. Other than 3rd party crystal reports and external reporting tools running faster, the SQL version is actually slower than the regular client/server version due to this. And as Jerry said, I'd love to see the expression on a CEO or CFO's face if you said to them what you posted as the advantages of moving to 2013 with/sql. The handful of features, you mention, may or may not help the client. Do you know how many times, if at all the existing invoice number length was a problem? If its a problem, mention it, if its a feature for features sake, they will say 'so what'. And making a MOTM seminar statement like 'you need 2013 because your competitor doesn't use a system with TLM authentication' should be good for a few laughs. Please don't take the tone wrong. I'm not mocking or criticizing you. Just that the message is very programmatic and I doubt would fly well in the real world.

Mark's comments lead me back again to my main take away from FOTF implementation: it only works if you actively keep your consultative sales hat on. That is, you must constantly be asking and answering the question, ""What is the business manager trying to do better?"" The feature/function elements of your solution are only relevant as supporting statements to your solution to his/her problem's solution. This is very hard for most IT/ERP specialists, and as a result I am skeptical that more than 20% of them will adopt it well. I also double down on Mark's warning about Sage 100 and SQL. You need to be very (and I mean very very VERY) specific with them about exactly what they envision doing with this new back end. I assure you that a seasoned SQL IT guy will expect to do things with Sage 100's SQL that are not feasible. Walk carefully in this area.

The SQL advantages were cut and pasted from somewhere... don't remember. Copied or not, they are valid high level advantages. As Jerry pointed out, and I agree, these potential advantages need to be interrogated to determine there applicability to the customer. I disagree that the SQL version of MAS runs slower. My experience is different. I have several clients running SQL and reports are much faster. Updates are faster. It needs to be configured correctly or performance can be poor.

Was the SQL being compared to the Client/server ON THE SAME HARDWARE? If it was new hardware, then its not apples to apples

Many internal IT staff push for VM Ware or Hyper V. I argue adamantly against it. Same goes for Win Server SBS... Win Server Standard, lots of processor, lots of memory, and SQL Server Standard. Sage 100 ERP on the same server. No printers, no Active Directory, bare bones.

Of course, not every new feature will have value for every user. As pointed out, it is my job to wade through the features and discuss the relevant ones with the client to determine its value, if any. @MarkChinsky - I would not make a ""blanket"" statement like 'you need 2013 because your competitor doesn't use a system with TLM authentication' (BTW it's TLS not TLM). I may however make a similar statement only if it is relevant to the business. For example, using TLS may not on the surface appear to be a competitive advantage. TLS (or other relevant features) could have other advantages such as compatibility, which lowers TCO, which is a competitive advantage. For example, I have a client using MAS version 4.45. They implemented Exchange 365 using TLS authentication. Email using MAS paperless office isn't compatible with Exchange 365 using TLS. The workaround is to install an internal SMTP server that routes email to the Exchange 365 SMTP server. To this client, there would be value in the 2013 TLS compatibility feature (and not laughable). I appreciate the comments from all of you. It has helped me consider how these features can add value (or not) . Agree or disagree, it is always interesting to learn how my colleagues with similar issues handle these situations.

I think we all would be interested in what you come up with for this customer. Maybe just the higher-level points you used?

I will keep you posted. I had a meeting with them last Tuesday to gather information for my value proposition.

One of my first sales training classes instructed to frame presentations (and proposals) using an Objective/Benefit/Feature approach. What are the customer's Objectives? What are the benefits of the recommendation that point to the Objectives? What features of the recommendation allow the benefits to occur? The feature isn't important. It is helping customers reach objectives that counts. The feature of expanded invoice numbers in AP doesn't matter. Improving processes because employees no longer have to ""make up"" invoice numbers in order to enter data and then explain to vendors what invoice is actually being paid provides the benefit and helps the customer meet objectives. The feature is improving efficiency and accuracy. Those are the benefits. Improved efficiency and accuracy can reduce costs and improve goodwill. (Objectives)

The SQL conversation could be what keeps this customer interested in upgrading regardless of the technical implementation done by Sage. I had a company with 175 companies go to SQL. they liked the idea of being able to run reports easilly across all 175 companies without much effort. We can do silly stuff like - Which companies are not closed for July yet. This saves them valuable time going in and out of each company. Or being able to do a business alert for duplicate AP invoice numbers if keyed into a different company. While I completely agree - there are still areas that the SQL version does not perform like it should, it is offset with all these other now features that were not as easy to do as before.

@JohnnyPabian I'd love to see a separate post where you expand on the pros and cons of Sage 100 Premium (SQL). I may be giving customers outdated information and generally indicate that if the primary reason for moving to SQL is to increase Sage 100 processing speed then they should save their money. It would be very helpful to have a more detailed pros/cons list -- similar to what you just said but maybe with some expanded observations or comments?

SQL value exhibit A: I write a ton of pvx utility programs, as well as use VI to move data in, out and around the ProvideX DB. With SQL, in many cases, you can create a SQL statement in much less time it takes to write a pvx utility or a VI job. There is a lot of value there.

But writing back to SQL instead of Vi is a liability waiting to happen. There is no referential integrity or rules in Sage's implementation of SQL that would make that a good idea.

What's the difference does it make in terms of liability whether you use ProvideX or SQL to write to the SQL db ?

ProvideX, true...VI, a big difference. I'm not against sql. Hell, sage is about 15 years late to that party and should be embarrassed they still sell a version that shares large open files over a LAN. It still means a bump in cost, as it always has and a loss in compatibility with some modules and 3rd party options. Even if you sell the client on 2013, should be interesting how you justify another 21 to 42% (depending on how long until the next release) after they've moved to sql

VI is a UI used to generate a ProvideX program. When you create a VI job and compile it, a ProvideX executable is created . You could manually write the code to accomplish the same task.

Yea but VI always follows the business logic and rules. Writing to sql blows it out of the water. One bug in your code and you have a permanently corrupted ERP system.

Gratefully, I've never had an issue. I try and follow the rules (most of the time). We are a development partner and we do it all of the time. Yes, we have made errors, but never a ""permanently corrupted ERP system"". Back it up, make the change, QA the heck out of it, and put it into production.