Despite a heavy meeting schedule at this year’s Convergence, I was able to attend many of the keynotes and product sessions.  Lots of great information there and plenty of exciting announcements, most of which has been covered very extensively, especially the news about the upcoming release of Microsoft Dynamics for the cloud.   However, for my money, one of the coolest demos there was a tool that became available last year with the release of Dynamics GP 2010 and is looking better and better.   That’s Dynamics Business Analyzer.   

Dynamics Business Analyzer is an analytics tool that’s provisioned directly inside the GP homepage, similar to Business Portal.  Using that same metaphor, they’ve made some significant improvements for pushing out information from Microsoft Dynamics to the non-Dynamics users in your company, such as the executive management or sales team.   And, with Windows 8 and the Metro UI, you can access API type information from Dynamics using the Business Analyzer toolset on your tablet or smart phone.  What does that mean?  It means you get away from Internet Explorer.  So it’s almost like removing a layer - you no longer have to go through a URL because the information is coming directly through  Windows 8. 

The demo at Convergence was recorded and is available after a very brief registration at the Virtual Convergence site.   That’s well worthwhile, and allows you to view some popular sessions, to give you a little flavor of the conference.  However, if you just want a quick idea of how Business Analyzer works with a mobile device and what it looks like in a real life setting, I highly recommend the two very short Youtube videos called out in a blog post by one of Microsoft’s long-time Dynamics experts, Errol Schoenfish.  Both are under three minutes and get right to the point.

As always, if you’re interested in discussing Microsoft Dynamics for your company, I’m here to help.

 Myth number three in our series on myths about ERP selection and implementation is:  

“Customizing/configuring an integrated ERP system is preferable to adding best of breed solutions, because you’ll still have an out-of-the-box solution after customization, which is much easier to implement and maintain.”   

This myth seems to have been promulgated in recent years as ERP vendors have added more tools to enable configurability.   While this is a trend that we can all be happy about, a great deal of confusion has risen over where configuration stops and customization begins. 

The short answer to this question is that customization involves writing code.  However, vendors may sometimes use the term “configuration” in a less than accurate manner, leading customers and prospective customers to believe that an entire module can be "configured."  Creating something where nothing existed before generally involves writing code.  Even if it's done with the tool set that is part of the product in question, someone will be writing new code with that tool set to create the heretofore missing functionality.  

This can complicate and substantially raise the cost of implementations and maintenance, and make upgrades a great deal more difficult and expensive.  And, these changes run the significant risk of relegating your company and solution to a “community of one.”  For more about the dangers of going solo in the areas of software development and software ownership, you may also be interested in reading “The Dangers of Customized Solutions – Part I” and “The Dangers of Customized Solutions – Part 2.”

As an alternative to customization, I’d suggest that you look at available best of breed solutions to fill gaps in your out-of-the-box ERP solution.   Service oriented architecture (SOA) has opened some doors for integration improvements that simply weren’t there when the “integrated systems vs. best of breed” argument first began.   

"Out-of-the-box" and "customized" are mutually exclusive.  The benefits that you're looking for in an out-of-the-box solution are often met with best of breed solutions.

 Continuing our "Myth-buster" series, here’s Myth #2 about ERP selection: “A detailed RFP will help you filter out products and/or vendors that don’t fit your needs.” 

This might be true if it weren’t for the fact that some providers will over-state their capabilities during the RFP process in order to be considered and to move to the next step.   In these cases, the RFP process actually incentivizes dishonesty – a bad way to start a relationship.  And, while prospective customers may sometimes realize later that they’ve filtered out honest providers who are just as capable as the not-so-honest ones who were short-listed, at some point there’s no turning back. 

I think RFPs are more useful as a detailed checklist, provided to the vendor that’s been selected.   After you’ve made a final decision, using this detailed checklist provides a final confirmation that you haven’t missed anything as part of your due diligence.   Using this as a final step in the process – at the same time that you’re checking references – supports a more realistic self-appraisal from the vendor and helps set expectations for the implementation before the project starts.

It may seem counter-intuitive, but we've seen this work well for several customers.  Let me know if you're interested in more details about how this worked.

 This will be the first in an on-going series on this topic, authored by several of us here at Tensoft.   I’ll start at the beginning of the process – selecting an accounting and/or ERP system. 

The first myth that I’d like to discuss is: “To make a good decision about which ERP system to choose, you’ll need a detailed RFP (Request for Proposal) to send to each vendor that you want to consider.”   Ostensibly, the purpose of an RFP is to gather detailed information about your selection criteria, make an “apples to apples” comparison of the vendors, and evaluate them based on scoring a weighted analysis of their answers.   In reality, RFPs often simply amount to a waste of everyone’s time.   (A significant waste, since completed RFPs can be hundreds of pages.)

Here's why.  Years ago, the RFP process sometimes uncovered glaring deficiencies and red flags.  Today, however, the General Ledger modules of the top ten accounting systems just aren’t functionally that much different from each other.   In many ways, the functionality differences between the most popular systems are insignificant enough that they’ve practically become a commodity.   Because of this, the analysis provided by an RFP process today is more likely to turn up red herrings than anything truly problematic or outstanding.

What’s the alternative?   Instead of creating and evaluating massive RFPs, invest time into drilling into the exact nature of the business problems that you’d like your new system to solve.  For example, many of our customers have very complex revenue, billing and/or contract management scenarios that they previously developed massive spreadsheets to handle, because their system of record’s core functionality didn’t handle their needs efficiently and effectively.   Once you’ve identified the specific areas that are particularly painful  to try to address with your current systems and processes, you can then look for systems –and vendors - that are differentiated by their ability to solve those particular issues.

The result?  A streamlined selection process that skips rather pointless comparisons of ubiquitous features, and dives straight into the issues, allowing you to quickly identify who and what can solve them. 

 I love software – it’s been one of my passions as an adult, both professionally and in my leisure time.  While there was a time when I made my livelihood delivering customized solutions to businesses, the places where this approach is useful have greatly decreased.  Over the last 15+ years, I’ve seen some of the serious harm that can come from dependence on highly customized solutions – even those that supporters may rush to defend as “just configured.” 

In this first part of a series of posts on this topic, I’ll focus on the danger that I call “a community of one.”  This unique and lonely “community” is the result of the fact that customized solutions – by definition - have only one customer for the software code that has been written just for them.  In a community, you benefit from collective knowledge and collective investment.   Providers of commercial (rather than custom) software have access to community knowledge and investment that is continually supplied from a number of customers and partners, as well as prospective customers.  There’s no way for one company to duplicate this – the benefits simply aren’t available to a community of one. 

In order to justify a customized solution, it needs to provide enough values to offset the loss of this community knowledge and investment benefit, as well as the other dangers discussed in my next posts.  To be continued….

 While not uncommon, starting with an MRP system and adding ERP later does present some unique challenges.  I would strongly recommend keeping two things in mind: 1) the eventual integration between MRP and finance; and, 2) the finance needs from the MRP system.  Both are important, and both require financial involvement from the start, even if manufacturing goes off on their own.

Going a little deeper on the first point, it would be wise to review your financial system options related to the manufacturing system now, as well as the available integration with these systems.  Be aware that "integration" may be used to describe anything from moving a few bits of data back and forth by a spreadsheet upload, to a full end-to-end ERP.   I would recommend that you define what you mean by integration in your requirements - for example, is it one version of truth, platform compatibility for consolidated reporting, robust auditable integration points, all of the above, or something else entirely?   You will also want to understand the value of integration for your organization - how important are benefits such audit transparency, information velocity and accuracy, and personnel efficiency, to name a few?  Given the extra work that will be required to make separate systems function in your organization, is the perceived cost benefit trade-off of delaying ERP really worth it?

As for the second point, financial requirements are often ignored when finance and manufacturing functional groups proceed separately with systems.  This is almost always a mistake.  MRP functionality usually includes sales operations support (sales orders, shipments, possibly invoices and credit management, bookings analysis) as well as inventory cost (inventory value change, inventory sub-ledger, margin analysis) and procurement management (payables, purchasing).  A significant amount of your financial input resides with your manufacturing system – a decision made in isolation usually leads to disappointing results.  Best to work together from the start for a unified solution. 

 A: There are a few ways to interpret this question. I will interpret it as follows: “How do you explain the lower training costs associated with running SaaS compared to conventional on-premise models?”

There is a general expectation -- especially for companies that have under $50M in revenue -- that implementation of SaaS software is lower in cost than traditional models.  We sometimes find that this expectation extends to training, and it may be assumed that training cost is not required.  However, most experienced folks expect there to be support and training for any type of system transition.

In general, this expectation is backed up by what the market offers.  There are definitely some tasks that are no longer required in a SaaS world, starting with system administration training and support.  However, there are a number of factors to consider related to this lower cost. I’ll attempt to address these below.  After that, I’ll add a few cautionary notes for executives who are looking to manage training and implementation.

Drivers for lower training and implementation costs:

1)    The general trend in ERP over the last ten years has been to move toward a best-practices implementation model.  At its most basic, this model states that there are a number of configuration options to which most companies default, based upon market and product experience – and these assumptions are built into the implementation rather than covered uniquely each time.  At its best, this model should be adapted to your specific industry (vertical) so that the best-practices are based upon comparable organizations.

2)    There is an increased “do-it-yourself” expectation that goes with SaaS modules.  This expectation is supported by online training sessions (recorded or otherwise), short remote training sessions instead of day-long commitments, and the general expectation that the customer team will roll up their sleeves and contribute heavily to the conversion effort.

3)    There is also a general expectation that software is getting easier to use – or that web-based software should be easy to use.  This is an area where I suggest extreme caution, since complex business processes or configurable options definitely require background training.  On the whole, systems have become better-understood with some convergence of transaction metaphors.

A couple of cautionary points to consider:

1)    There still are custom implementations in the world: where the project is unique to your company; where everything is configured uniquely to you; or where the software is adapted to your exact specifications.  Most people do this sort of implementation only when the uniqueness adds to your competitive advantage in the market rather than as standard practice.

2)    SaaS does tend to commoditize some types of functionality.  It is best to think about this related to training as well. Look at the areas that add the most value to your company and the areas where you expect to be business-standard.  Expand or contract the levels of training and support where you receive the most benefit.

3)    Be careful in your transition from the sales process to the implementation process.  If you need to document the expectations discussed in training for internal review within your company, do so.  Purchasing a best-practice-based system, streamlining it for do-it-yourself implementation and then managing it like a unique customized training implementation generally leads to poor results.

  After two days at keynotes, meetings and more meetings at Microsoft’s Worldwide Partner Conference (WPC), we’re feeling better than ever about Tensoft’s focus these days.  Between our long-time vertical industry focus, our commitment to the cloud, and our Gold ERP Competency, almost everything that we’re hearing here supports and validates our goals.

During Monday’s keynote session, Steve Ballmer cited a 20% compound annual growth rate over the past 10 years for the Dynamics product line.  In the National Strategic Partner FY12 Kickoff meeting that we attended today, nationally managed partners were credited with driving a substantial portion of this growth. 

In another meeting, a Microsoft executive noted that 25% of this year’s 15,000 WPC attendees are Dynamics partners - remarkably high considering all of Microsoft’s other product lines that partners represent. 

As expected, there has been a lot of focus on the cloud this year.  But, we’ve been pleasantly surprised by the focus on Dynamics, and glad that we made the effort to be at both WPC and Convergence in 2011!  

 While Tensoft has been a Microsoft Gold Certified Partner since 2004, it’s never been as difficult to meet the requirements as it was this year.  That’s because of deliberate changes that Microsoft has made to their Partner Network Program.

IDC analyst Darren Bibby does a great job explaining what’s happened in his blog post, “Microsoft Partner Network - Can We Bring Back Meaning To ‘Gold’ Please?”   In brief, Bibby says that, in recent years, about 50% of all Microsoft Partners were able to attain Gold Partner status.  His point, of course is that:  “50% is not such an elite level.”  By contrast, Microsoft’s Partner Network website states that, currently, “only 1 percent of Microsoft partners worldwide that have attained this outstanding degree of proficiency.”  Now that’s a little more elite!

The other programmatic change that Bibby mentions is that the new Gold and Silver (which is now the top 5%) levels are associated with specific “competencies,” each focusing on very specific knowledge and expertise.  Combined with the more rigorous requirements for Gold, this ensures that a Microsoft Partner that really excels at what they do within these competencies is easily identifiable to customers, partners, and Microsoft employees.  

Tensoft is especially proud to have attained the Gold level for the ERP Competency this year, demonstrating our excellence in the skills, expertise, and resources needed to successfully deploy financial and supply chain management solutions for our customers.  One percent out of approximately 640,000 partners is not bad – we’re honored to make it, and we congratulate all of the other Microsoft Network Partner members who made it as well. 

 In case you missed this recent announcement, Tensoft Revenue Cycle Management (RCM) recently passed Microsoft's highest standard for partner-developed software and is now "Certified for Microsoft Dynamics" (CfMD).  This certification consists of a rigorous testing process performed by VeriTest, to demonstrate product development quality and compatibility, as well as at least 10 confirmed references.  (Many thanks to our customers who helped with this requirement - we were done in well under the average time for completion because of your help!)

Those were basically the same requirements for the CfMD that we had the last time that we went through this process, when we certified Tensoft Multi-National Consolidation.  This time there was one key difference though - the addition of a requirement to have a Source Code Escrow Account. 

This new requirement seems to get short shrift in discussions/articles about CfMD, but we see it as one of the key benefit to customers of CfMD products.  Without it, the CfMD benefits have the potential of being short-lived, providing cold comfort to unlucky customers.

A source code escrow account isn't something new for Tensoft - we've had an Iron Mountain account for years.  Having weathered two significant economic downturns since we started business in 1996, we've counted our blessings as we watched much larger companies fail.  While we feel pretty good about surviving, it would be foolishly arrogant to believe that we're now somehow "immune." 

We buy insurance to protect against adversity, and our Iron Mountain account is insurance that we buy for our customers.  We see it as a great investment in customer service!