The International Accounting Standards Board (IASB) and the Financial Accounting Standards Board (FASB) have recently published important exposure drafts on “Revenue from Contracts with Customers.”  The proposed joint standard seeks to clarify the principles for recognizing revenue and to adopt a single revenue model for both International Financial Reporting Standards (IFRS) and US Generally Accepted Accounting Principles (US GAAP) reporters, across industries and markets.  If adopted, this would represent a significant step toward global convergence in financial reporting.

These proposed standards will likely result in significant changes in the key financial performance measures of many companies, in many industries.  For most, this will require changes to the business management systems that measure and recognize revenue, as well as updates to revenue recognition process controls.  Although the effective date is no earlier that January 1, 2015, it’s not too early to prepare, since this may take substantial planning and effort to implement, depending on your company’s current contract and revenue processes.

Tensoft will be providing further insight to our customers, partners and other interest parties, including an upcoming webcast on March 13 – just in time to help inform any additional comments that you’d like to make on the exposure drafts! 

 The first danger we discussed is the community of one – the fact that custom development has only the input and funding your company can provide without the group knowledge and contributions that a wider community of users from multiple companies allows.  The second danger involves development resources for custom solutions.  Often this represents another “community of one” – in this case, one developer who is responsible for your code.

This is a potentially dangerous scenario, because software development depends on multiple areas of expertise.  There are data architects, systems analysts, developers, test analysts, business analysts, and so on.  Each brings deep expertise to the challenge – the deep business knowledge and the understanding of how to translate that into technical requirements, the best way to store and structure the data for scalability and efficiency, the best way to handle the data flow requirements both internal to your solution as well as integration to other solutions, and separation of the test function and code configuration management, in addition to the challenges of coding the required customization. 

This is not to mention the support process for custom code.  The more customization is used,  the more support required , the greater the challenges of upgrading solutions around the customization become , and the more required ongoing investment from the developer.   For many companies, dependence on a single custom developer – or even a small team – may be an unacceptable risk.  Certainly you can take precautions to minimize the risk and impact on your company by storing source code, combining a mix of internal IT resources and outsourced talent, bringing in high level expertise to review design documentation for bigger development efforts, and budgeting for the required level of support after coding is complete.  However, in a world moving to the Cloud -  a world where people are looking to move system administration and support costs outside of your company -  customization needs to be very carefully reviewed for both  potential benefit and the real cost involved.

 The numbers are in, and 2011 is now officially a big year for SaaS growth here at Tensoft, with a 24% growth rate in annual billings from Cloud-based offerings.  For a year when many similar businesses lost market share and had to cut back on their investment activities, we're pretty pleased at these results.

Here's what Tensoft President and CEO Bob Scarborough had to say about this: "Having hosted applications since 2005, Tensoft made a concerted company decision to re-energize its web native software strategy on Cloud-based offerings during the trough of the recession in 2009 when it was unpopular to make tough investment choices.  As a result, we are now more than two years ahead of a number of our competitors and enjoying double digit SaaS billings growth."

In addition to achieved 24% annual recurring revenue growth, Tensoft had a number of other notable successes in 2011, including:

• Added a record number of new customers, including leaders in the software, semiconductor and technology industries.
• Tensoft Revenue Cycle Management software earns Certified for Microsoft Dynamics accreditation.
• Successfully replaced multiple competitors' customer sites with Tensoft applications.
• Tensoft earns gold level in the Microsoft Partner Network ERP competency.
• Hosted Momentum 2011, the sixth annual user conference for Tensoft Fabless Semiconductor Management's worldwide customer base.
• Tensoft High Tech Dashboard (HTD) product selected as one of the top 15 most useful add-ons worldwide for the Microsoft Dynamics GP business solution.
• Bob Scarborough, Tensoft CEO, speaks at GSA Semiconductor Ecosystem Summit.
• Sponsored eight CPE-eligible webcasts and training courses for software and high tech industry professionals.
• Added strategic partnerships with leading advisory firms for the promotion and delivery of Tensoft's revenue management applications.
• Tensoft Cloud data center operations maintained SAS 70 certification and ISO 27001 registration.
• Approved as an educational webcast and seminar provider by the National Registry of CPE Sponsors.

 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. 

 During 2011 the semiconductor and high tech industries witnessed natural disasters in Japan and Thailand cripple their supply chain, starting with the disruption to supplies of parts, to the subsequent shutdown of contract assembly and test facilities.  Consequently, risk management of future natural disasters and strategies to better plan for future supply disruptions have been the subject of much discussion among industry and business thought leaders. 

Two of the key lessons learned include:

1) The criticality of implementing a geographical, multi-sourcing strategy.  While reliance on a same region subcontractor based on ease of maintenance or volume favored pricing may provide convenience, the reality of disruptions due to natural disaster warrants the assessment of alternate sourcing locations.

2) The importance of diving deep in Tier 2, 3 or 4 suppliers' sourcing relationships, confirming that they also  diversify their suppliers' geography. Otherwise, supply disruptions caused by natural disasters occurring thousands of miles away from your lower tier vendor's location may unexpectedly whipsaw product availability or suspend subcontractor services altogether.

A parallel may be drawn here to the process of qualifying of cloud computing providers. Many Software-as-a-Service (SaaS) companies maintain relationships with single location or same region data centers to host their customers' data. Take, for example,an ERP SaaS company which maintains data centers located throughout California.  In the event of a catastrophic  earthquake, serious disruption of services to its customers may be inevitable. Regardless of the number of data center locations utilized and possible safeguards, the fact remains that dependence on a single geographic region greatly increases risk.

Be it a semiconductor company or SaaS provider, black swan events such as those from mother nature may be greatly minimized through a multi-geographic sourcing strategy.  And, like companies who depend on the semiconductor supply chain, companies who depend on SaaS providers would do well to include some inquiry into their data center sourcing strategies as part of a thorough due diligence process.

 Revenue management functionality is available either as part of a few financial and accounting software solutions, or as an independent solution that provide some level of integration to your system of record.  Vendors on both sides can be glib about their product’s ability to handle anything that you can think of.  If your company is in either the technology or software industries, you’re probably well aware that your needs in this area are beyond what most solutions are designed to handle.  When in doubt, be sure that the vendors that you’re considering can demonstrate - not just talk about or give a slick slide presentation on - the following capabilities:

1)    Ability to handle multi-element arrangements.

2)    Robust support for fair value methodology.

3)    The system can match the transaction flow of your go-to-market model(s), providing, for example, contract administration or integration to your website or CRM system.  

This is just a starting point, of course, but these three points will help narrow the field a bit.

 When software companies are interested in Tensoft's Revenue Cycle Management (RCM) product, we first try to determine a fit for their requirements, so that no one's time is wasted.  Even if they have not yet created a requirements document, we find that a lot can come out of considering these three variables:

1) Billing. How does your company go to market (eCommerce, enterprise agreement, channel model, etc.)?  You'll want to look for a billing system or a billing support system that matches your go-to-market model.

2) Revenue Recognition. The rules for software industry revenue recognition are complex and changing. For the basics, you'll need a sub-ledger for deferred and recognized revenue analysis and appropriate methods and models to support your revenue recognition models.

3) Revenue Compliance. Could be part of the above, but is often a sub-set of that, and one that not every company needs.  There is no easy way to describe this, but if you have a sales process with multiple related elements in it (like software plus maintenance), and there are different recognition periods for the elements, you are most likely subject to more complex accounting guidelines.

Tensoft Revenue Cycle Management (RCM) supports billing requirements as well as complex software revenue recognition and contract management.

   While there’s been plenty of hype regarding the benefits of Cloud Computing and SaaS, a commentary by Proformative’s John Kogan in Forbes – “Defining IT Differently” – provides a very reasonable argument.   Kogan argues that moving to the Cloud and/or SaaS solutions reduces the number of IT staff needed at companies who do this, but that those who are left are more strategic.

I agree that this shift changes the composition of your IT team.  How it changes the composition depends on where you are in your company history.  Smaller companies who move to the Cloud will no longer need as many system administration staffers, such as desktop support and support for your engineering team.  Subsequently, the shift to the Cloud allows smaller companies to bring in a business analyst(s) at a much earlier point than they normally could afford to – definitely a strategic IT position for most companies.  While it still desirable to have someone on staff who understands what your Cloud provider is doing, and there may be some tasks you need/want to do on your own, the move generally means a reduction to system administrators and hardware specialists.

Kogan touches on another point that I see as one of the most significant benefits of the Cloud - the ability for companies to have access to far more – and better – hardware, technology and support in the Cloud than they could economically source for themselves.  This democratization allows smaller companies a more level playing field, and it also makes the Cloud a comparative money saver if you consider all of the costs that go into it (labor, hardware, replacements, training, etc).  This comparative cost savings is a point that is often over-sold and misunderstood – it’s a powerful benefit, but “the Cloud is cheaper” is not an accurate picture.