nav2015Word is that Microsoft plans to release the next upgraded version of Microsoft Dynamics NAV late in 2014.  More information is expected to be forthcoming at the NAV Directions Conference in San Diego in September.  The product (formerly code-named “Crete”) will simply be named Microsoft Dynamics NAV 2015.

[Several PSSI staff will be attending the Directions conference, Sept. 9 -13, and we’ll have more news to report in a future post.  In fact, we’ll be back by the time this post is published, so stay tuned for further announcements.]

Among the tidbits of information already announced this summer by Microsoft:

  • Easier upgrades! (The sound you hear is the cheering of both customers and resellers.) The improved upgrade capabilities will include “new tools to upgrade and manage data more easily” according to Microsoft GM Erik Tiden.
  • Better integration with Microsoft products like Office 365, and more Power BI integration built directly into the product.
  • New mobile device support, including a tablet interface for Windows, iPad and Android, for a more consistent “app experience across devices”.
  • A new role-tailored NAV home page that includes “expressive tiles,” colored squares that indicate not just standard metrics but any business information that can be derived from NAV. Color coding logic can be defined for each tile.
  • “Significantly improved” browser performance.
  • And from what we’ve heard more recently, the ability to use Microsoft Word to design report formats. This is an exciting development for all users and developers alike, we believe.
  • Also hinted at: Improved cash management functionality and “simplification.”

When our team returns from the September Directions Conference we’ll undoubtedly have more to share with you.  Stay tuned…


cloud_money_imageThe website technologyevaluation.com recently wrote about why, despite all the chatter these days (good and bad) about The Cloud, manufacturers are not rushing into SaaS (Software as a Service) based enterprise resource planning (ERP) products.  Their points are worth noting, which we’ll do today in brief, adding our own commentary where appropriate.

  1. Multiple modification requirements. Manufacturing is complex, often including high volumes of unique transactions.  ERP systems for manufacturers almost always must include consideration for unique customizations.  While some cloud ERP products can accommodate low-level changes, the SaaS model in general is the antithesis of a customizable solution.  While software publishers may hope you buy in – so they can host and serve the same software once across many paying customers – the model is not such a good fit for most manufacturers.  A system with ‘standard’ functionality will usually not meet the demanding requirements of today’s manufacturer.
  2. Data ownership and overall increased dependency on a third party. From temporary outages to “the theoretical possibility that a provider might file for bankruptcy” (in the words of com), along with the simple logistical concerns about the availability of one’s data, cloud solutions pose a distinct risk to manufacturers.  You’re putting your company data in the hands of an entity you do not control.  On the other hand, you may already be sharing lots of your company data with your bank, creditors, suppliers or others, and thus already sharing to some degree.
  3. Strict compliance requirements. Cloud ERP providers may or may not be able to accommodate any unique compliance regulation relevant to your particular niche.  Your requirements may simply not match up well with a provider’s infrastructure, deployment method or, for example, a requirement to use separate servers for separate functionalities.
  4. Security concerns. Cloud providers will increasingly be heard boasting about security that’s even higher than on-premise solutions, and increasingly those boasts will ring true.  However, it’s always been the case with security that the weakest link is not in the data center – whether that be on-premise or off-premise – but rather, with the user.  On-premise systems can in some cases provide high–levels of field or record level data security; some cloud providers may offer this with their Service Level Agreements, but not all do, and it can be expensive.
  5. Leasing vs. Purchasing. Although leasing a la cloud offerings seems cost-effective in the short run (and it is), it’s often just the reverse in the long-run, that is, when taking a total cost of ownership (TCO) view.  Think of it this way: Are you the kind of auto buyer who likes a steady ongoing lease payment that never ends, or are you more inclined to buy on payment terms, content in the knowledge after a few years that ‘now I own it’ and the payments have ended?
  6. Integration with other corporate applications. ERP systems frequently need to integrate, usually in some data reach-out or back-door manner, with other internal systems.  Your ERP system will likely need to integrate with other cloud and on-premise systems.  This is almost always true in manufacturing firms.  The total cost of doing so will often be higher in the cloud deployment model than might be the case in a strictly on-premise environment.

While some or all of these considerations can be mitigated by cloud solutions, the real question is the cost and complexity of doing so.  In all cases, special due diligence is highly recommended.

As the old saying goes: You know who the pioneers are, right?  They’re the ones up front with the arrows in their backs.  Proceed accordingly.


erp pricingThis is the last post of a 4-part series on ERP pricing, and the why companies first need to complete a Business Process Analysis before acquiring a new software system.  It reflects the cumulative lessons gained from 25 years’ experience implementing ERP and MRP systems.  The first post is found here.



MRP II pioneer Ollie Wight used to say that “People are the A item.”  Data is B, and the computer is C.  Today, we’d insert “Process” between A and B.  Consistent processes, known and understood by your people, are the key.

So what do you end up with from the BPA?

The BPA produces deliverable benefits, namely: Your company learns about itself, and how things really work – and that knowledge is then documented.  With a Business Process Analysis:

  • Management – and key staff – are engaged
  • Key processes are documented, at least at a high level
  • A roadmap for your implementation is outlined

And as a result you end up with:

  • A well-defined list of project goals often based on KPIs (Key Performance Indicators)
  • A clear sense of required functionality, by phase
  • A prioritized project task list
  • A general sense of the size and scope (and roughly, cost) of your project
  • A fact-based foundation for a subsequent software & services estimate
  • The ability, finally, to make an intelligent decision about what you want to do next

That last point is important.  Without the BPA, you don’t know whether your project will cost $X, or $3X or $5X.  Since you know in your heart that most of the work of a BPA must be done at some point in your project, doesn’t it make sense to separate out that piece of the engagement?  You can spend a little money upfront to learn the scope of your real needs before you spend a lot more money. Wouldn’t you want to know the answer to that question before you put down money on a new system?

It’s done on a modest, fixed-fee basis (at least at our firm).  And you get to know the caliber of your potential implementation team long before you make any larger financial commitment to them – almost like a test drive!

What do you lose if you don’t do the BPA?

We built an entire case study [ask us for a copy] around a client who hired us only after they first did it the other way – without the BPA.  The bottom line was this: What they thought was going to be a $125,000 project was nearly twice that by the time they called us in.  Numerous modifications and more change orders than they could count later, the project was headed toward 300% of budget, and they still weren’t live.

It’s not that the high cost wasn’t valid.  But don’t you think the owner would like to have known that before he started the project?  He made it clear to us he did.  With a BPA, he could have – indeed would have – made a better-timed, more intelligent decision.  A modest investment upfront would have yielded a clearer picture of the project’s true costs.

In the end, the old cliché once again proved true: It doesn’t cost, it pays.

You’re not just paying for a quote.  You’re buying insurance.  And saving money in the long run.  Call it peace of mind.  For a modest fixed price at that.


erp pricingThis is Part 3 of a 4-part series on ERP pricing, and the why companies first need to complete a Business Process Analysis before acquiring a new software system.  It reflects the cumulative lessons gained from 25 years’ experience implementing ERP and MRP systems.  The first post is found here.


The Analysis Process

Clients who really think through their needs eventually come to the conclusion that some kind of workflow and process analysis is necessary in order to begin to solve their problems, increase efficiency, reduce costs, improve inventory, lean out processes, eliminate redundancies, and ultimately keep them competitive, support their growth and boost their bottom line.

That’s why at our firm we do the BPA as a separate engagement.  Clients are under no further obligation to us after that.  If you determine you don’t want to go with our recommendations or services, you can still use the BPA as a project roadmap to select other software.  We do this deliberately for two reasons:

  1. It protects you the customer by having you commit to a tiny part of the overall project, before you make a costly commitment to any specific software.
  2. Over the past 4 years, we have not done an ERP project without first doing a BPA. We can honestly say that every client expressed satisfaction with the results of the BPA.  They learned about themselves, their processes, their gaps and their opportunities.  They were engaged.

We start by reviewing a client’s process and workflows.  This typically requires two or three of our most experienced consultants, on-site for two or three days, meeting individually with up to a dozen key members of the client’s team – including the CEO and CFO.  We delve into the arcane details of every key department and process, gaining knowledge about how each functions, the obstacles they face, the challenges they see.  We talk about what they like and don’t like about their current system.  We review their answers to questionnaires provided in advance of our first BPA visit.

We will later map those processes through flowcharts, often comparing ‘current’ and ‘future’ states.  We’ll identify technology touch-points that will make them more efficient, remove redundant data entry, eliminate steps and roadblocks and integrate disparate areas, reports or software.  We’ll try to strip away the superfluous and redundant, and plan for software and very experienced consultants to help move them, carefully, to a leaner state.

The end result is a written ‘Summary of Recommendations,’ typically of about 30 pages that will map everything we’ve learned, suggests key priorities, breaks efforts down into prioritized phases wherever possible, and yield a final report that we’ll discuss in person, usually before any decision has been made about which system is right for you.

And yes, there is a cost associated with this effort.  The good news is that it’s a lot less than you might think.  But it still isn’t cheap.  BPAs run from $10,000 to $15,000.  But the good news is that they can (1) save you many times their cost, and (2) let you know in advance if what you thought was an $X dollars project is more likely a $2X (or $3X) dollars project.  With the BPA designed as a separate engagement, its small investment can save you a lot of money, or make you a much more informed buyer when you become one.

When all our hours are added up, it’s really a loss-leader from our perspective.  The hours charged rarely match the effort rendered.  It’s simply our way of ‘putting a little skin in the game.’   We put a substantial effort into mapping your processes, and then charge a fraction of what we should to (1) show you good faith and (2) prove our competency.

In our final post, we’ll look at Results.  Stay tuned…

erp pricingThis is Part 2 of a 4-part series on ERP pricing, and the why companies first need to complete a Business Process Analysis before acquiring a new software system.  It reflects the cumulative lessons gained from 25 years’ experience implementing ERP and MRP systems.  The first post is found here.


Where to Begin

We are often contacted by a business after it has come to the inevitable conclusion that the software on which they run their business is simply no longer up to the task.  Whether that’s because it’s a pre-Y2K relic… or a hodgepodge of disconnected ‘silos of information’… or the progeny of some earlier homegrown solution… or simply because the firm’s growth has outpaced its software’s capabilities… the decision has been made to find new software.

So we get a call from a prospective or existing client.  As we discuss our experience and process, we ask questions, explore their needs and suggest a site visit.  After more questions, a tour, a discussion about next moves and a few war stories, we usually suggest the key first step: the Business Process Analysis.

First, we should point out that the Business Process Analysis (BPA) has a minor role in helping to select which ERP system is right for you.  True, it helps there, but… its real purpose is to help your company learn more about itself, and only then gauge the size and scope of the actual project.  We usually back into ‘which’ software from there.  The BPA is rooted in a simple premise: we cannot quote what we do not know.

We start by explaining what a BPA is.  How it allows us to define and understand a company’s current key processes.  How it allows us to project what a future-state process may look like.  How it creates the very roadmap that tells us, and anyone else, your key goals and how simple or complex your project is.

At this point, we typically hear one of three responses:

“The other guys will do that for free.”  Sure they will.  We’ve seen examples.  Typically, it’s a brief fly-by, maybe a few pages in a report, describing your business in general terms and how their software will help improve it.  Most “free” analyses are worth what you paid for them: a bit of high-level fluff and perhaps some technical jargon aimed at getting you to commit to a specific piece of software — and its accompanying vendor’s services — long before you truly know what problems you are trying to solve.  It won’t give you a roadmap for your journey, and it certainly shouldn’t convince you that Software Brand X is just right for you.

“We’ll start laying out the processes after we’ve selected the software.”  A slight improvement.  At least this answer acknowledges the fundamental need for the analysis.  But it’s still putting the cart before the horse.  It’s tantamount to making the process analysis Phase One of the implementation project itself.  The problem with that is you’re doing it after you’ve selected software and a vendor.  By that point, you’ve committed a lot of money already to software and services that you don’t necessarily know will actually solve your problems.

“Before we can approve a process analysis, we’ve gotta’ have at least a ballpark number.”  Okay, we’ll concede this point… sort of.  As noted earlier, we can ballpark a software price quote based on general functionality and user counts — emphasis on ballpark, but it’s valid.  But services estimates can be all over the map, and no one can prove or disprove them because the necessary work to validate them has not yet been done.  So even an estimate can be off by a factor of five.  Easily two or three.  Being off on a price estimate for an ERP implementation by a factor of two or three is enough to get yourself canned.

In our next post we’ll take a brief look at The Analysis Process.  Stay tuned…

erp pricingThis white paper reflects the experience and counsel of a long-time provider of ERP / MRP software systems.  Unlike many of our ERP-related blog posts, which are often based in comments first proffered by others, this one comes straight from us.  The experiences, opinions and comments offered are strictly our own.  They are based on 25 years of experience evolving through the many wrong ways, and finally the few right ways, which we’ve found over time will result in a successful ERP implementation.


The Dilemma

Anyone who has spent much time providing business software systems has heard the question above – probably many times.  When we tell prospective clients that a lot of work needs to be done before we can even begin to give them an honest and realistic appraisal of the cost to automate their business, some turn incredulous, if not indignant.  “Why should I pay you to give me a quote?” is the common response.  They think they’re being asked to “pay for a quote.”

Read on to learn what experience has taught us about the real answer to the question.

If you want a software quote, that’s easy – up to a point.  Really good software for a small to midsize business will typically will run you about three or four thousand dollars per user when all is said and done.  This will typically include accounting, inventory control, front/back office functionality (AP, AR, PO, SO) as well as some manufacturing functionality like bills of material, routes, and so on.  That may drift up or down a bit depending on number of users, desired functionality and so on, but it’s a good ballpark figure.  (It’s worth noting here that our specialty is working with distributors and, particularly, manufacturers whose needs often tend to be pretty complex.)

On top of the base software, there will be services.  That’s the big one.  We can quote you a rate per hour, based on a published rate table (the larger block of hours you purchase, the lower the rate).  But no, we can’t tell you how many hours it will take, because neither you nor we have a clue how long it will take!  We don’t know what works at your company and what doesn’t.  We don’t yet know what you want to automate.  We don’t know how smart your people are, or how complex your processes, or how committed your management team is… and we certainly don’t know how all those pieces work, or fit together (or don’t), or how you want it all to look in the end.

So in order to provide clients with a meaningful estimate of services, we have to do some work.  A lot of work, actually.  Put another way: We cannot quote what we do not know.  So how do we get to the point where we can actually tell a client what’s involved in implementing their ERP system?  The short answer is something we’ve come to call the Business Process Analysis.

But since a BPA is a billable engagement, it’s right around this point where a small but vocal percentage of prospects hit us with the question: “Why should I pay you to give me a quote?”

We’ll look at Where To Begin in our next post.  Stay tuned…


Get every new post delivered to your Inbox.

Join 89 other followers