While MRP and its successor ERP have been regarded as necessary tools for manufacturing for decades, the truth is, early MRP and ERP solutions didn’t support the needs of the engineers very well. That set the stage for engineers to go off and do their own thing, often and very successfully avoiding any connection to other applications. If there was a connection, it was arm’s length. Engineers sent paper drawings and electronic bills of material (BOMs) over to manufacturing where they tended to take on a life of their own.

That might work well enough from a pure product design point of view. Yet in reality there is much more to a product life cycle than just design and manufacture… as well there should be. For example:

• Do you co-develop with customers or partners?
• Does marketing coordinate and collaborate with engineering on new product introductions?
• What about the list of suppliers of raw materials and/or components?
• What about the cost and impact of engineering change orders?
• Do changes made in manufacturing ever make their way back to the engineering design?
• Do you service and repair your products?
• Does customer feedback influence product innovation and design?
• How about feedback from service technicians or sales?

Of course it will take some discipline on the part of the NetSuite/Autodesk customers, but tight integration between ERP and PLM will remove many of the reasons engineers have struck out on their own to purchase and implement solutions. With this integration, product concept, design and engineering data are developed in Autodesk. Once released, bills of material (BOMs) are fed to ERP.  Engineering can also suggest vendors from which to source component parts. But these need to be approved by purchasing within the ERP and confirmed back to PLM with a handshake.

Engineering change orders (ECOs) can also be managed with the same level of automation and control and gives the engineers added visibility to the impact on cost and profitability as well as capacity.

But probably more important in terms of change control is the bi-directional aspect of the integration. How often does manufacturing feel the need to tweak a design for manufacturing? Do those “tweaks” ever get communicated back to engineering?  If not, the next change order from the engineers could be a nightmare. Integration ensures that changes are properly documented, propagated and managed in both PLM and downstream manufacturing.

The bi-directional integration can also have an impact on both quality and innovation. Without that closed loop from manufacturing back to engineering, there is an increased the risk the engineers can operate from an ivory tower. Quality issues are hidden without feedback from manufacturing operations and including suppliers in this feedback loop makes it that much more effective.

But NetSuite is also proposing the seamless integration will enable a cycle of innovation. In many industries, most notably in (but not limited to) consumer electronics, the expected life spans of products are shrinking. It’s not enough just to close the loop between manufacturing and engineering. It is equally important to capture feedback from customers and partners to understand customer acceptance. NetSuite is positioned to capture that feedback from CRM, service and PSA modules.

This is strictly a marketing agreement. NetSuite and Autodesk do not sell each other’s products. They will however work together on a deal. Expect them to work cooperatively and collaboratively.

And of course, it wouldn’t be an announcement from NetSuite without a reference to cloud. This partnership is unique in that both solutions were born in the cloud, designed specifically to be multi-tenant solutions deployed as Software as a Service (SaaS). So while it might be stretching it to say this was a marriage made in heaven, at least it is up there in the clouds.

NetSuite is buying OrderMotion for its expertise as well as its products. OrderMotion’s products are typically sold stand-alone and that will continue. The target is not current NetSuite customers. So this is more a market share play than it is one that goes after an increased share of the customer’s wallet. NetSuite intends to continue selling the OrderMotion product but it also hopes to apply some very specific expertise to further strengthen its own current order management capabilities. The OrderMotion engineering team will continue to innovate the acquired product but NetSuite also hopes to have them contribute to the order management modules of its ERP suite.

NetSuite already has a strong order management solution with capabilities that include distributed order management, fulfillment from multiple locations and return merchandise authorization (RMA) as well as strong back-office integration with billing and cash collection. It provides standard integration to major carriers like United Parcel Service (UPS), Federal Expres (FedEx) and the United States Postal Service (USPS). It can deal with multiple currencies and multiple sales and use tax structures. OrderMotion will add more depth of functionality in orders “direct” from the consumer and trends in the industry towards omni-channel commerce.

Omni-channel refers to the ability to use different channels simultaneously. Consumers might purchase online, but pick up, or return merchandise at a physical store. Retailers may use retail stores as distribution hubs. As consumers make online purchases, it may be advantageous to ship from a store location where the item may be overstocked, thereby drawing down surplus inventory. Or the choice of ship from location may be made to minimize cost and lead-time. Combining all these options requires a level of expertise and feature functionality not typically included in your traditional ERP software suite.

This is definitely an issue for retailers today. But more and more manufacturers and distributors find themselves also selling direct now, so it is just a matter of time before they need to deal with omni-channel supply chain issues as well.

In continuing to sell OrderMotion stand-alone, I would expect the acquisition to be accretive. But behind the scenes I would also expect to see the OrderMotion team lending a hand to further extend distributed order management and omni-channel supply chain capabilities in NetSuite’s ERP suite. Both solutions have a strong technical architecture that supports multi-tenant SaaS, so business models are consistent. But they are different architectures. While I don’t expect them to be sharing code, I would expect them to share designs.

NetSuite ERP will benefit from the expertise of a team dedicated exclusively to order management, one that has specific omni-channel expertise. OrderMotion engineers should also benefit from having to blend this functionality into an integrated suite, something they have only done at arm’s length previously.

Overall NetSuite winds up with a new product and a better way to attack the retail market that is already forced to deal with this omni-channel phenomenon. And it has the opportunity to further strengthen its existing product as the omni-channel commerce begins to invade the world of manufacturing and distribution.

About a year ago, returning home from Inforum 2012, I struggled with this. It certainly wasn’t for a lack of announcements. Honestly, there were no less than 21 different press releases talking about everything from the reinvention of the company under its new leadership to numerous technology and product announcements. But mostly these announcements were about strategy and what this new leadership was planning for a company that was obviously changing dramatically. The theme of the conference was “Go Faster” but it was clear that while Infor was out of the starting blocks, it was still very early in the race.

Now, a year later, in leaving Inforum 2013, let me just say, finding something compelling to write about is definitely not a problem. Having hired 650 new developers, not only is Infor “going faster,” it has already completed a few races.

This year there were at least 25 different announcements and that didn’t even include the surprise proposed acquisition of TDCI (product configuration). Announcements emphasized a continued focus by Infor on not just verticals, but micro-verticals, and the new release of Infor 10x. Announcements were sprinkled with a little cloud and a big dose of technology in the form of industry-specific use cases for its “purpose-built” middleware ION technology.

Because I prefer to have any one paper, report or post to be “about” a single topic, the problem this year will be prioritizing what I write. To give you a preview of what’s to come and some highlights from Inforum 2013, here’s what’s on the table:

• Loosely Coupled Versus Tightly Integrated: The Infor Perspective I recently  did a post that referenced Infor briefly, but was more about SAP’s introduction of Financials OnDemand. It posed the question, “Why should CFOs care?” It’s time to give Infor its turn in the spotlight to dive deeper into Infor’s overall strategy.
• Is “Convergence” a Dirty Word? Any solution provider that has grown largely by acquisition (as Infor has) must make a decision as to whether or not to rationalize its product portfolio. Thus far Infor has very consciously and conscientiously avoided a convergence strategy, promising not to discontinue support of products and to never force customers to migrate to new solutions. But when you have customers continuing to run on systems based on seriously outdated technology, does this do them a disservice?  In these cases, even a slight shift in strategy can make a huge difference in encouraging these customers to move forward. I’m sensing this shift in pockets of Infor even as it still insists on “no convergence.”
• Collaboration is Key: Helping Employees Ming.le Ming.le (pronounced mingle) is Infor’s new platform for enterprise collaboration, which it describes with minimal use of the word “social.” I find that refreshing. Designed primarily with the Gen-Y folks in mind, it uses a lot of the concepts and approaches popularized by social media. But by describing it more in the context of triggering alerts and helping those receiving the alerts come to a resolution quickly, it makes it much more “real” even for baby boomers who might not intuitively see how those types of tools can save them time and effort.
• Introducing Infor Sky Vault: Infor’s answer to big data? You can’t pick up a trade journal today without being confronted with the concept of big data. We “get” it. The volume of data we deal with for decision-making has been growing for decades. Now it is growing exponentially. Not only are there limitations inherent in traditional databases, but more and more data is floating out on the Internet that is not even captured in a structured database. Solutions are emerging to break down those barriers and Infor’s Sky Vault is one of them: a cloud-optimized data repository powered by Amazon Redshift, available through Amazon Web Services (AWS) at a very reasonable price. Because of the traditional difficulty in dealing with massive volumes of data, business decision-makers have essentially learned to “do without.” Now they have to learn about what is possible. Infor’s job now is to help them, as Infor’s James Willey puts it, “see the vision.”
• Microverticals: Will they save the day or become an enormous burden? The message at Inforum was clear. Forget a vertical focus. Infor is all about micro-verticals. Think dairies, breweries, meat packagers or bakers versus “food and beverage.” The ultimate goal of attacking a micro-vertical is to offer a more customized solution, without customization.  That’s the upside. The downside is the sheer volume of micro-verticals and the burden this places on Infor. Obviously the answer lies not in having entirely different solutions for each micro-vertical. The only way Infor will survive and thrive in this environment is through the effective use of its “purpose-built” middleware (ION) that will allow them to develop components of functionality once and re-use. So how does this work?

I could go on and list more possible topics of discussion resulting from all the different technology, product, acquisition and customer announcements. But I think this is a good start. What do you think? What would you like to hear most about?

But is this what its customers and prospects are looking for? That’s hard to say because it is very unlikely its typical prospect or customer really understands the intended “benefits” of loosely coupled.  In fact, when you start talking about “loosely coupled” to CFOs you are likely to produce that glazed look that says, “I don’t know what you’re talking about… and I don’t really care.” If you refer to “loosely coupled” in contrast to “tightly integrated” you might get a glimmer of understanding, but not an immediate acceptance of the concept.

CFOs might intuitively understand the value gained from tightly integrated applications, particularly in reference to an integrated suite of modules like ERP. After all, who wouldn’t want a complete solution, one where all the pieces just sort of fit and work together, with no integration effort required and no redundant data? While there might be some inherent value to having a loosely coupled solution, that value is not intuitively obvious to a CFO. Yet the opposite is true for both Infor’s CEO Charles Phillips and representatives of SAP, including former SuccessFactor CEO, now SAP’s chief “cloud” guy, Lars Dalgaard. They see enormous value in loosely coupled. As a result they either don’t see a need to explain it, or they have difficulty in explaining something they just intuitively “get.” Either way, the message is just not very clear to your typical financial executive.

So let me try to explain. The biggest reason “loosely coupled” might be of very significant value to a CFO is because things change. Markets change. Companies expand (or shrink). Software is enhanced. Technology innovation happens.  In fact, technology innovation often results from change but is also often the catalyst for change. Yet responding to change is hard.

Let me give you an example that should resonate with a CFO. Let’s say you are the CFO of a mid-size manufacturer who has helped your company expand over the past 10 years.  You implemented an ERP solution back when you were small and your accounting needs were rudimentary. You chose a solution for its strength in managing inventory and production. While you started out operating from a single location, you have expanded globally and now operate in 6 different countries around the world. While the financial modules of your ERP met your needs when you first implemented it, now you struggle with compliance and tax regulations, multiple legal entities, multiple currencies and consolidation. This is a very real scenario. Our latest Mint Jutras survey on ERP indicates 75% of companies today operate with more than one location. Even small companies (those with annual revenues less than $25 million) have an average of 2.6 locations and this average grows to 7.5 in the upper mid-market (revenues from $250 million to $1 billion).

You’d like to move to a newer, more feature-rich accounting solution, but your ERP is still satisfying the needs of manufacturing and since you are continuing to grow, you don’t want to disrupt the business by ripping it out and replacing it. The very thing that attracted you to your solution is now holding you back. Because it is tightly integrated, you can’t just replace a piece of the puzzle without replacing the whole thing.

To make matters worse, your older ERP solution is not really meeting your needs for customer relationship management (CRM). This is not surprising. While the footprint of ERP has been steadily expanding over the past 10 years, the needs of sales and service organizations were not front and center from the beginning. If these needs had been met with early versions of ERP, companies like Salesforce.com would never have taken off like they have. Maybe you too are considering adding a stand-alone CRM to the mix. If so, SAP might be pitching its Customer OnDemand solution in addition to Financials OnDemand.

So is this building a case against tightly integrated, in favor of stand-alone solutions that might need to be integrated? Not necessarily. In a tightly integrated solution there is only one of anything – one chart of accounts, one customer master file, one item master, one supplier master, etc. But these master files are shared across different functions. Purchasing needs to access the supplier master to place a purchase order. But accounts payable also needs a supplier master in order to make a payment. Sales and order management need to maintain information in the customer master, but accounts receivable needs a customer master to apply cash receipts. Pull the accounting solution out and you still need the suppliers and customers. Does the new accounting solution have its own supplier and customer files? Does this mean maintaining two of each? Does the new CRM add yet another customer master? If so, how do you keep them in sync? Or maybe you don’t. But this adds all sorts of new wrinkles.

“Loosely coupled” applications could very well make your life easier. But what’s the difference between “loosely coupled” and what used to be called “best of breed?” This is where it gets harder to explain and I am not entirely convinced all vendors that claim to deliver it are talking about exactly the same thing. It took SAP several tries before I really saw the difference, and I live and breath this stuff. Your typical CFO doesn’t.

In trying to understand SAP’s definition of “loosely coupled” I described the scenario above to the solution marketing team for SAP’s cloud-based financials and asked how the combination of Financial OnDemand and Customer OnDemand would address this issue of redundancy. If each were sold separately (i.e. not delivered as the integrated suite of Business ByDesign) would the customer wind up with two different customer master files? SAP’s answer was no.

Here’s how it works: Think of the customer (master data) as a business object. An older ERP solution will build that customer master file (the business object) right into the solution. Instead, these OnDemand solutions treat the customer master as a separate business object that lives outside of the application. By doing this, both applications can point to, access and reference the same business object.

But what about maintenance? Instead of building the maintenance functions directly into each application, SAP treats that function as a separate function as well. Instead of building that directly into Financials OnDemand and Customer OnDemand, SAP builds it once and puts it in a “business process library” which both (and other) applications can use. The term “business process library” might be a bit confusing because most think of business processes in the context of processes like “order-to-cash” or “procure-to-pay” or “plan-source-make-deliver”. These are workflows that string together different functions. But in this case the business process is much more granular. It refers to the process of maintaining the customer master data.

So by loosely coupling these two applications, the customer still winds up with one customer master file. And both applications use the exact same functions to access and maintain it. These external business objects sort of plug into these applications.

This solves an important problem, but in our scenario, where we are replacing the accounting applications of an existing ERP solution, it is only half of the problem. If that existing ERP is still managing customer orders, it too needs to access the customer master file and it probably assumes the customer master file is the one that is delivered embedded in the ERP. So until or unless you do some potentially invasive surgery to the existing ERP, you are going to have to deal with some redundancy of data.

Of course if you replace that tightly integrated ERP solution with a newer or upgraded solution that has been assembled with loosely coupled external business objects, this problem goes away. In the meantime, SAP, and potentially other solution providers are beginning to re-architect their solutions to make this much easier. They are essentially performing this surgery and delivering applications that make better use of underlying supporting technology to make this happen. Remember the $6 million man and the bionic woman? They were still people, but with some of their “parts” significantly enhanced. Think of it as bionic ERP.

Last Friday I attended one of SAP’s Startup Forums in the Boston area.  Dr. Sam Madden, who runs MIT’s CSAIL (Computer Science Artificial Intelligence Lab) presented the keynote for the event. While most might think the concept of big data is self-explanatory, Dr. Madden actually defined it as follows: Big data is data that is too big, too fast or too hard for existing systems and algorithms to handle. Big data, by Dr. Madden’s definition, might eventually go away. Not because there is less of it, but because we are better equipped to handle it.

SAP is certainly trying very hard to make this happen and its Startup Forums are manifestations of this effort. While this is the first of its kind in the Boston area, SAP has been holding these around the world for a while now. The format is interesting. Think of it as speed dating between really bright technologists and potential investors (including SAP Ventures and its $155 million venture fund). Picture 15 different startups in a room, each with five minutes to give their pitch on who they are and why their ideas are the next best things in the world of big data.

Why is this a match made in heaven for these guys (and yes, sorry, but every single one of them was male)? Because these brilliant minds come up with truly creative ideas and often need funding to get them (and their products and services) off the ground. SAP is looking for promising startups interested in developing solutions on top of the HANA platform. SAP doesn’t ask for money, code or intellectual property (IP).  It provides an SAP HANA test environment and development licenses, a development boot camp and technical support at no charge until the startup runs live on HANA. At the point when HANA is embedded in a product, SAP will begin to see some revenue.

Of the 15 presenting, some were already participating in the program; others were potential participants. Some made the HANA connection in their pitches; some did not. Dr. Madden suggested (and a panel of partners from technology investment companies from the area agreed), “Big data is over-hyped. It is a new name for something we have been doing for the last five years.” But he also acknowledged awareness of and access to new data as a result of the convergence of some major trends. We have the digitization of data. We’re collecting more because of the emergence of inexpensive sensors, access to cheap computing and storage and an increasingly connected world.

While it might be over-hyped, big data is not going away any time soon. There is still plenty of opportunity based on current solutions’ inability to handle the volume of data that already exists and is emerging from these trends. That’s probably a good thing for SAP and other vendors jumping on the in-memory and big data bandwagon. Right now SAP HANA’s value proposition needs big data. But do customers and prospects see that? And do they see HANA as the solution?

It is clear that those bright technologists presenting their ideas recognize this opportunity and HANA’s potential. As do the 170 live customers of HANA and the other 40-50 that have HANA projects underway. But this is still a very small sample of the 232,000 SAP customers worldwide, 80% of which are small to medium size enterprises (SMEs). Does the typical SAP customer (or prospect) understand what HANA can do for them? The answer isn’t just, “No.” The real answer is, “Hell no!”

SAP’s single biggest challenge in bringing HANA to market is not in developing the technology, but in describing it in a way that helps average business people understand what it can do for them. So far SAP has largely described it as an elegant technical solution in search of a problem. It also suffers from having initially described HANA as an in memory alternative to a traditional database. Dennis Howlett has summed it up the best of any I have seen so far in saying,

“HANA is much more than that. While it might have started out as a poorly thought out (Oracle competitive) database play, it is a development environment that is providing ISVs with extraordinary opportunities to rethink business processes as well as providing the real time platform for both analytics and the transactional systems.”

But the average enterprise, particular an SME isn’t looking for a development environment.  This explains why HANA has been most successful in large enterprises where you have large IT staffs with big budgets and lots of problems to solve. But that is not how the vast majority of businesses spend their budgets, particularly SMEs. They are looking for a solution to a problem, but they don’t want to develop a solution.

The typical SME won’t develop a HANA solution. It will seek a solution developed on HANA. This is why the SAP Startup Forum is so important- to provide solutions to all those potential problems. Lots of problems, across lots of industries will require lots of solutions.

In the meantime SAP is also making its ERP solutions available on HANA thereby providing some important differentiation in a market where in some ways traditional ERP has become viewed as a commodity. But HANA will not differentiate SAP’s ERP solutions until or unless business leaders understand what HANA can do for them. ERP will run faster, but unless speed is a barrier to doing business, the business won’t pay much (if anything) to make it faster.

Businesses won’t pay to make life in general better. But they will pay to solve a particular problem or overcome a particular challenge. The challenge SAP faces is first in helping those business leaders identify those problems and secondly to convince them the problem is indeed solvable.

For those of you in my generation, think back to the phone you had in your childhood. For me it was a rotary-dial, three party line. Our biggest problem was calling a neighbor who shared our party line. If you had told us we could have a phone that would allow us to snap a picture and instantly send it to someone, not across town, but halfway around the world, we wouldn’t necessarily have jumped at the chance. First of all, we probably wouldn’t have believed you. Secondly, we wouldn’t have perceived the need to do it.  We just didn’t think like that.

It took us many years and many generations of technology to get from that rotary dial three party line to today’s smart phones and networks, with all the inherent capabilities. Something tells me it won’t take us 50 years before business leaders start demanding what HANA has to offer, but we’re not there yet. In the meantime, it is safe to say big data is here to stay.

• reduce the cost and effort of investigation, by providing tools to better detect new and changing fraud behavioral patterns
• redirect efforts away from false alarms in order to deter and possibly even prevent a fraudulent transaction from being completed
• and of course… earlier detection by processing high volumes in quasi real-time

What Is It?

SAP Fraud Management is part of SAP’s Governance, Risk and Compliance (GRC) product portfolio, along with Process Control, Access Control, Risk Management and Global Trade Management. It is part tool (for the IT department) and part analytic application (for fraud investigators).

The potential for the solution was demonstrated at the SAP Insider GRC 2013 conference in Las Vegas using an example from the insurance industry. Michael Lortz, Sr. Director, Solution Marketing for the GRC portfolio of products played the role of an investigator tracking down a potentially fraudulent automobile insurance claim. A young policyholder had submitted a claim after an accident that had occurred between 1:00 and 5:00 AM. The detection engine flagged it as suspicious due to the combination of the age of the operator and the time of day the accident had occurred.

The first step Michael, as the investigator, took was to do a “network analysis” to look for the same set of circumstances in any other claims. Come to find out this young claimant, and two others involved in the accident were also participants in four other claims. What are the chances this kid had five different legitimate accidents involving the same people? Slim to none? Obviously the perpetrators of the fraud were counting on the sheer volume of claims processed to mask this. In fact, they were successful the second, third and fourth time. The fifth time around, with the help of some enabling technology, somebody noticed.

As a result, the transaction could be flagged as fraudulent before any payout on the claim was made. But more importantly, the engine that triggered this as a suspicious claim could be recalibrated to change the thresholds that trigger audits that would prevent, if not the second claim, at least the third and fourth. And through recalibration of the rules, the likelihood of any transaction flagged as suspicious turning out to be fraud is increased substantially. Tracking down “false alarms” is costly and unproductive. So the ability to reduce those “false positives” can represent a huge savings.

Part Application, Part Platform

So, is SAP Fraud Management an application or is it a set of tools from which a clever customer or an SAP partner can build an application? The answer is, “Yes.” It is part application and part tool and it relies on the HANA platform for some of its functionality. Of course, this example provides a compelling business case for the insurance industry. While this was automobile insurance, surely it could be tweaked for homeowners and other kinds of liability insurance. The net result is a complete, working application for this industry.

However, the processes of detection, investigation and deterrence are similar in managing any kind of fraud and can be pre-built into a framework:

• Detection based on a set of rules
• Analysis of a network of objects looking for similarities (participants in insurance claims in this instance, but just as easily dinner guests on an expense report, deductions on a tax return, etc.)
• Combined with a timeline (in what period of time were all these claims filed?)
• Documentation of decisions (e.g. not to pay a claim, to reject an expense or to conduct a tax audit)
• Add deterrents and refine the process by recalibrating the rules for identifying possible fraud

But the team building SAP Fraud Management didn’t have to create all this from scratch. It also looks to HANA to speed the investigation with its ability to process and analyze massive volumes of data, seemingly in real time since there are no spinning disks to traverse. All data is stored in memory, speeding the process. Rules are defined natively in HANA, while the “calibrator” is a specific tool created for Fraud Management.

Similar scenarios could be constructed for public sectors and the detection of tax evasion or perhaps abuse of social services such as food stamps or disability claims. Or it could help private companies detect fraudulent expense reporting or questionable purchases. Given the ACFE estimates the average organization is at risk of losing up to 5% of its revenue to fraud, the potential payback is more than significant. It can be huge.

Chances are SAP will not speculatively develop these industry-specific versions themselves. It is more likely for some of its partners to develop them. Most notably, we might expect to see some of the larger management-consulting firms with large risk management practices develop these for industries they serve.

Conclusion and Recommendations

If your company is at risk for significant financial loss as a result of fraud, SAP Fraud Management is certainly worth a look. First quantify the risk and then assess the cost of your current efforts to contain and mitigate that risk. If you employ fraud investigators, you must have some measure of their success and chances are you measure the number of potential cases investigated, along with the number of real occurrences of fraud. The goal should not necessarily be to increase the number of cases of fraud detected, but to detect fraud more quickly and to minimize the number of cases you chase that lead to no fraud (fewer cases of false positives). SAP Fraud Management, powered by SAP HANA can help you stop chasing down rat holes. This will allow you to set thresholds of risk lower and investigate more cases that can be proven fraudulent. Ultimately the goal is to maximize the amount of fraud prevented.

When NetSuite began its foray into manufacturing, it started out by describing its target market as “light manufacturing.” To those steeped in manufacturing tradition, this implied a simplistic assembly process. But over time, NetSuite refined its target to be “contract manufacturing,” defined as “you design, others manufacture.” As more and more actual manufacturing became outsourced and moved off-shore, this class of manufacturers became more common. Many manufacturers turned to low-cost country sourcing for not only components and subassemblies, but for the entire manufacturing process.

This transition removed some of the complexities that first MRP and then ERP needed to contend with. Manufacturing can be a delicate and complicated juggling act: having the right amount of inventory (enough but not too much) at the right time, effectively utilizing labor and machine resources while scheduling potentially long and complex processes. If a contract manufacturer didn’t actually manage the production, much of the complexity of managing this delicate balance is removed, eliminating the need for some of the feature functions at the very core of traditional MRP solutions. However, the trade-off was to introduce more supply chain complexity as multiple companies, often with conflicting goals, needed to effectively interoperate to optimize the process from raw materials to finished product.

The need for this elevated level of interoperability is something I have been writing about since before NetSuite was even in business. Back in the mid-90’s I talked about the concept of virtually vertical manufacturing (VVM): Multiple companies working cooperatively and collaboratively to produce and distribute a product as if it were a single, vertically integrated enterprise. But back in the 90’s the concept of virtual integration was still ahead of its time. The Internet was still relatively “new.” While folks could appreciate collaboration, interoperability between companies still required more traditional buy/sell instruments like purchase orders, sales orders, shipment notices and payments. Paper documents were being replaced by electronic documents, but very, very slowly and often at an arm’s length.

Today the need for technology-enabled integrated business networks is something that any progressive manufacturer understands. But many are still running older legacy solutions without the technological infrastructure to support this level of interoperability. Hence they are not well equipped to participate effectively.

This puts NetSuite at an interesting juncture. As many manufacturers are re-evaluating their previous outsourcing and off-shoring decisions, NetSuite in its latest release is now adding functionality that older manufacturing solutions have supported for decades: features like effectivity dates on bills of materials, component where-used visibility, detailed operational routings and capacity requirements planning. But those older solutions were developed on legacy architectures that limit the solutions’ ability to support the level of interoperability, collaboration and coordination required today… interoperability that is built into NetSuite. So while many of those solutions are busy “modernizing” for secure web-based access and adding functionality such as integration with CRM and sales forecasts, building web-based store-fronts, those features are already supported through NetSuite’s native core.

Meanwhile NetSuite is playing “catch-up,” adding these as fully integrated, technology-enabled features and has the potential of leap-frogging the established solutions. At the same time NetSuite, is extending the Suite, adding many complementary capabilities such as payment gateways, support for electronic tax preparation and electronic filing in eight new countries, and adding even more features for collaboration and visibility that many today refer to as “social.” And it is continuing to develop the underlying platform and development environment, which helps it grow its ecosystem. It is through this ecosystem that it is able to extend the footprint of its solution much faster than if it were to rely exclusively on its own development efforts… think manufacturing execution systems (MES), quality, product lifecycle management (PLM) and asset maintenance.

This is an opportune time for NetSuite to be at this crossroad, not only in order to expand its addressable market, but also because we are seeing new dynamics in terms of globalization. While for several decades we have seen manufacturing moving off-shore, with the instability of oil prices, currency fluctuations, and the rising cost of transportation, rising costs in previously low-cost source countries and continued concern over quality and compliance from emerging markets, we are now seeing an increasing trend back to near-shoring or even on-shoring. This could easily cause those contract manufacturers to bring some of that manufacturing complexity back in house. If so, they will require more of these traditional features. But it is unlikely their supply chains and global operations will be simplified.

This puts NetSuite in a competitive position because it is far easier to build new features and functions on a technology-enabled infrastructure than to try to modernize outdated technology. In answer to our initial question, it is looking more and more likely NetSuite can indeed catch up and maybe even pull ahead of those “mature” solutions for manufacturing.

Indeed, in its “Next Generation Shared Services – The Strategic Plan” the government includes the following as one of its key objectives:

“To ensure that a lower cost Enterprise Resource Planning (ERP) solution is available as part of the ISSC solutions, to reduce the cost of the current ERP solutions, and to remove the barriers to entry for smaller departments and ALBs by reducing software and maintenance costs through consolidation. Without the provision of single ERP systems and therefore single processes the Government will struggle to reach its upper quartile efficiency targets and therefore testing this will be an early part of the programme.”

So as part of the deal, the UK government gets a new ERP. Arvato will replace the existing SAP solution with the cloud-based Agresso Central Government ERP platform in a phased migration. Interest in cloud-based software as a service (SaaS) has definitely been on the rise over the past few years. And so has interest in replacing existing ERP solutions.

In 2012 Mint Jutras posed the question, “Is it time to purchase a new ERP?” Based on data collected in the second half of 2011, only one in four of you said, “Yes!” Another 24% were undecided but over half (51%) gave us a resounding, “No.” We explored the possible reasons for replacing existing solutions. We shared with you the average and “World Class” results that could be achieved, suggesting that those of you not in the market for a new ERP might want to reconsider. New technology and robust feature functionality available today will put older solutions to shame and you might be missing out and missing out big time.

Many listened. The percentage of those looking to purchase a new solution more than doubled in our latest survey. In our most recent 2013 ERP survey, when we asked the same question, many more (56% to be exact) said, “Yes, we intend to purchase a new ERP within the next 3 years.” Twenty percent (20%) are still on the fence but only 24% said, “No.”

Lack of functionality, outdated technology and the inability to scale with growth of the business have traditionally been the top three reasons prompting actual replacements and this year was no different.  In terms of potential replacements: functionality and technology also claim the top two spots, but the possibility of reducing the overall total cost of ownership through a replacement appeared as a significant driving force, along with the emergence of standards being applied across the enterprise. Compared with the quest for fit, functionality and enabling technology these are relatively new motivations, but a motivation indeed for the UK government.

How does spending time, effort and money on a new solution result in savings? Given the scope, replacing ERP will typically require cost justification in order to estimate the expected return on the investment. But return on investment (ROI) is different than total cost of ownership (TCO), particularly in terms of enterprise applications. ROI calculations often only include up-front costs.

Harder to calculate are the post-implementation costs in managing change. And managing change remains as the top challenge identified in achieving the goals of ERP. ERP solutions based on outdated technology are likely to be rigid, making adapting to change expensive. Architectural agility to accommodate change is important to everyone but for ERP buyers faced with frequent or massive changes, it is absolutely essential.

UNIT4’s solution is a quite natural fit in this case. UNIT4 actively seeks ERP buyers faced with frequent or massive changes, or those it refers to as “Businesses Living IN Change (BLINC).” It prides itself in the solution’s ability to easily adapt to business change. This should be important to the UK Government for two very different reasons…

The public sector is not immune to business change. In fact it faces more than its share of changing regulatory requirements, financial management-driven change, as well as the need for new or changed business processes.

The second reason is that the DfT is only the first of several departments to be supported. Other departments will likely present new, previously unanticipated requirements. This represents additional change, but also requires flexibility if the ERP is to become the standard across these different departments.

Two very good reasons for selecting a solution that specializes in post-implementation agility.

On January 10, 2013 SAP announced the availability of SAP Business Suite powered by SAP HANA, a new option for SAP Business Suite customers and an opportunity for SAP to deliver “transformative innovation without disruption.” That’s a mouthful, but one that has the employees at SAP super excited. While the announcement was well-received and the audience seemed to like what it heard, this group of IT influencers didn’t seem to exhibit that same level of excitement. But influencers can be a jaded bunch. All too often as you start to dig deeper you find the story just isn’t all that new or different. In this case I believe the tables will be turned. As influencers and SAP customers alike begin to explore and understand the new and very real possibilities, what first appeared to be just “interesting” will truly become exciting. And there is no limit to those opportunities to innovate.

The HANA Story: What It Means to Business

Part of the reluctance to “feel the excitement” might stem from the fact that we’ve been hearing about HANA for a few years now. Six years ago Hasso Plattner, cofounder of SAP and Chairman of its Supervisory Board, had a vision of what the system of the future would look like. That vision included:

• All active data must be in memory. In Hasso’s words, he wanted to “get rid of the rusty spinning disk.”
• Full exploitation of massively parallel processing (MPP) in order to efficiently support more users
• The same database used for online transaction processing (OLTP) and analytics, eliminating the need for a data warehouse as a reporting tool for OLTP to support live conversations rather than “prefabricated briefing books”
• Radically simplified data models
• Aggressive use of math
• Use of design thinking throughout the model

But such a vision obviously took time to deliver, so for the first few years the world heard about this transformative technology, but couldn’t touch, feel or see it. In 2011 we started to see some results as HANA for analytics became a reality and pioneering companies began to see performance improvements previously unheard of in terms of speed and the ability to handle massive volumes of data.

In 2012 it became real as SAP released HANA as a platform for developers. But the vision was still one of powerful technology and much of the talk over the past six years has been presented in very technical terms. “Here is this super technology; let’s work together to find ways to use it.” That’s not necessarily how business executives and non-technical decision-makers think. Instead they think in terms of business problems. “I have this problem. How are you going to help me solve it?”

While the ability to “support live conversations” and efficiently “handle more users” might resonate with a business executive, these messages were often over-shadowed. Business executives don’t necessarily perceive the value of eliminating disks, simplifying data models or using math. They don’t know what MPP is or design thinking.

So now, with this announcement, SAP is trying hard to change the conversation to be less about the technology and more about the business value.  What is the real value? In the words of one early adopter: HANA solves problems that were deemed unsolvable in the past.

It is in uncovering these types of solvable business problems that the excitement will build. As Dr. Vishal Sikka, member of the SAP Executive Board, Technology and Innovation said, “Now the software at the heart of thousands of the world’s best-run companies can work and think as fast as our imagination.” But many business executives simply don’t have the same kind of creative imagination as a Vishal Sikka or a Hasso Plattner.

SAP Business Suite might be reinvented on HANA but how does that help customers reinvent their businesses? The trick will be in unleashing their imaginations and helping them see the possibilities. Yet in its attempt to make the message universal and relevant at the highest levels of its customers’ organizations SAP often introduces a level of abstraction that is lost on its audience. So we need to translate some of these high level messages into something that might be a little more concrete.

Becoming a real-time business

SAP’s brochure says, “Becoming a real-time business requires managing daily business transactions of your core business processes in real time, such as finance, sales and production – and as well, to capture data from new sources like social media, mobile apps or machine sensors.” However, how many enterprises today have a stated goal of “becoming a real-time business?” They don’t. They have goals such as growing revenue or reducing costs to improve profits. They may or may not be able to connect the dots between those goals and collecting and analyzing data in real time.

For those dealing directly, or even one step removed from an actual consumer or consumer product, the value of data from social media and/or mobile apps might be intuitive. For these companies, their brand is of paramount importance and they take great risk in ignoring social media or opportunities to connect directly with potential customers through mobile devices. So adding this dimension to the decision-making process should be well-received once you get the customer to think in those terms.

For manufacturers of industrial products… not so much. The world is changing, but slowly. It is entirely possible for them to think “social” isn’t business; it is something someone does on their personal time. And mobile devices are what their kids use to text their friends, play games and listen to music. For those same manufacturers, machine sensors and automated data collection (ADC) devices may have been on shop floors for many years. Those sensors and devices may in fact have the ability to shut down a line of production before bad product is produced. But can the data be effectively analyzed in order to improve products and processes? It is very possible that vast quantities of collected data have been underutilized for years, for one simple reason – there is just too much of it. And because it is collected continuously and automatically, it is constantly in a state of flux.

That thought actually brings to mind a parallel in history that dates back to the 1970’s.

Will HANA Bring to IT what MRP brought to Manufacturing?

The business world hasn’t seen something with this kind of potential impact emerge on the market since the introduction of MRP in the 1970’s. Those outside of the world of manufacturing might not appreciate the real significance MRP had, but there are a lot of parallels between the potential for HANA and the automation of the planning process that MRP brought about.

In a nutshell, MRP (material requirements planning) takes a combination of actual and forecasted demand and cascades it through bills of material, netting exploded demand against existing inventory and planned receipts. The result is a plan that includes the release of purchase orders and shop orders and reschedule messages. While the concept might be simple enough, these bills of material could be many layers deep and encompass hundreds or even thousands of component parts and subassemblies. Without automated MRP there is simply too much data and complexity for a human to possibly work with.

As a result, prior to MRP, other ways of managing inventory became commonplace. You had simple reorder points. Once inventory got below a certain point, you bought some more, whether you actually needed it or not. You also had safety stock as a buffer, and the “two bin” system was quite prevalent. When one bin was empty, you switched to the other and ordered more. These simplistic methods may have been effective in some environments, but the net result was the risk of inflated inventory while still experiencing stock outs. You had lots of inventory, just not what the customer wanted, when it wanted it. And planners and schedulers still had to figure out when to start production and they knew enough to build a lot of slack time into the schedule. So lead times also became inflated and customer request dates were in jeopardy.

Once MRP entered the picture, these were seen as archaic and imprecise planning methods. Even so, most didn’t rush right out and invest in MRP when it was first introduced. In fact now, decades later, the adoption rates of MRP in manufacturing still sits at about 78%. Why? The existing practices were deemed “good enough” and, after all, that’s the way it had always been done.

It required a paradigm shift to understand the potential of MRP and the planning process executed by MRP was complex. Not everyone intuitively understood it. And if they didn’t really understand, planners were unwilling to relinquish control.

Yet over time, MRP brought a new dimension to material planning. It brought a level of accuracy previously unheard of and helped get inventory and lead times in check. Manufacturers can experience an average of 10% to 20% reduction in inventory and similar improvements in complete and on-time delivery as a result of implementing MRP.

Now with HANA we’re introducing the potential to improve processes, not by 10% to 20% but by several orders of magnitude. But it also requires a paradigm shift.

Manufacturers, as well as other types of companies, are quite accustomed to making decisions from a snapshot of data, usually in report format, possibly through spreadsheets. They have become desensitized to the fact that this snapshot is just that, a picture of the data, frozen in time.

What if you never had to run another report? Instead, whenever you needed a piece of data or an answer to a question, you had immediate and direct access, not to the data as it was at the beginning of the day, or the end of last week, but to the latest data in real time? That’s what Hasso envisions when he talks about “live conversations versus prefabricated briefing books.” But those used to making decisions from those briefing books need to be educated on the possibility of the live conversation.

And, oh, by the way, traditional MRP, a game changer in the 1970’s and 1980’s is in for a major transformation.  Early MRP, and even versions of MRP today took and still take a long time to run and need exclusive use of the data. So it is typically run overnight or over a weekend. Think of the possibilities if it could now run in minutes or even seconds. Is that possible? With HANA, yes.

“Transformative Innovation Without Disruption”

In his opening remarks Hasso introduced the concept of “transformative innovation without disruption.”  In fact innovation was a key driver for John Deere, the early adopter of HANA mentioned previously in the context of solving previously unsolvable problems. Derek Dyer, director, Global SAP Services, Deere and Company outlined three ways in which the company views HANA as a game changer:

• Bringing new innovation to the business by solving problems deemed unsolvable in the past
• Simplification of the IT stack while introducing the ability to deal with huge volumes of data
• Better serving the business by providing real-time access to data for better decisions

John Deere was originally attracted to HANA based on the performance aspects of the platform. The “Wow!” it was seeking was speed. It has had some initial success with its early projects, but sees a new world with ERP now on HANA. It intends to transform itself from a manufacturing company to a solutions based business. An example: It plans to take data from sensors in equipment in the field, determine how the equipment is being used, under what conditions. Not only will the data be real-time, but it will also allow them to answer back to the customer with very personalized, specific answers, and also support better collaboration with suppliers, dealers and customers.

Seeking Innovation

John Deere and other early adopters can provide some examples and perhaps some motivation, but each company will have to discover its own possibilities for changing the game. This is where SAP’s reference to “design thinking” comes into play. It is a protocol for discovering new opportunities and for solving problems.  It starts out with defining the problem. Because these problems might, as John Deere points out, have been previously deemed unsolvable, this step might not be as simple as it sounds. But it is the first critical step in finding that “excitement.” It can also be the most difficult. SAP and its partners can help.

What about Disruption?

The very term “disruption” is a source of controversy these days. Many talk about “disruptive technology” and refer to it as a good thing. But there are different kinds of disruption. A new technology that disrupts the way you think about problems and processes can have a very positive influence. But when new software (for example a new release of ERP) disrupts your business because you can’t ship a product or support your customer, it is definitely a bad thing. Upgrades to software like the SAP Business Suite are often viewed as disruptive in the bad sense, rather than in a good way. This is the kind of disruption SAP is promising to avoid.

Customers can take advantage of the Business Suite on HANA without upgrading their existing Business Suite. Current reports and customizations are preserved, including integration with other applications. And even partial migrations are possible. And there is no forced march now or in the future. SAP remains committed to supporting the customer’s choice of databases, including database technology and vendors. So the choice is left to the customer.

Yes, there is a cost associated with moving the Business Suite to HANA, but pricing for the new database works similarly to pricing for other databases even though the customer will experience huge improvements in speed, including 10 to 1000 times faster analytics.

Key TakeAways

It is clear that a key value proposition for SAP HANA is speed, but the vast possibility for business innovation trumps the value gained for improved performance. But each SAP Business Suite customer will have to identify its own possibilities for innovation. For some these opportunities for innovation may be staring them in the face. Others will have to dig deep into existing processes and identify those problems they have been living with for so long that they might appear to be unsolvable. Once uncovered, ask the very real question, “Can I solve this problem today with HANA?”

Jason comes to Plex after a short stint at Oracle, where he was senior vice president of application development after the acquisition of Taleo where he held a variety of executive roles. For those not familiar with Taleo, it has been a pioneer in cloud-based talent management solutions. So he certainly has the cloud credentials. But someone like me, who has grown up (professionally) in the world of ERP and manufacturing, but has also been involved with human capital management  (HCM) applications, including talent management, knows full well the difference in scope between ERP and HCM, particularly when it is ERP for manufacturing.

While those specializing only in HCM hate it when I say it, HCM is pretty intuitive. Everyone that has ever managed people understands the requirements for talent and workforce management. Anyone that has recruited talent knows what recruiting is about. We’re all human “resources” so we know about human resource data, benefits and compensation. But manufacturing is anything but intuitive. And the scope of ERP (and its role in managing the business) dwarfs that of HCM. And Plex isn’t the first ERP vendor to bring a former HCM executive in and put him in charge of something much bigger than HCM.

So Jason might have felt a little like he was on the hot seat yesterday when we spoke. And he will probably be a bit relieved to hear that what I heard yesterday was encouraging. While a lot of his background has been in HCM, including both Taleo and previously Peoplesoft, I learned he also worked as a management consultant for Price Waterhouse. And I also heard him acknowledge what he didn’t know about ERP and manufacturing, but that he was confident because the original founder of the company was still involved and he also had some great depth of expertise in the company, including Jim Shepherd, his VP of Strategy. Shep and I go back almost 30 years when we both worked for ASK Computer Systems, and our paths would cross more recently when he was an analyst with AMR, which was later acquired by Gartner. It was reassuring to hear that Jason understands the value of having someone with Shep’s depth of knowledge and vision for manufacturing.

Plex has enjoyed consistent growth over the past few years and even before the investment by Francisco partners had been self-sustaining. This is an incredible achievement in the world of SaaS solution providers, when many others far larger than Plex are still struggling to show a profit. It has one of the most active and engaged installed bases of customers in the industry. This is partly because of the close relationship between its customers and its product direction. For many years, the development organization was primarily driven by specific customer requested enhancements. Plex’s adoption of rapid application development methodologies allowed them to respond quickly and efficiently and deliver against these requests even with a multi-tenant solution.

But in order for Plex to take that next jump and grow globally into new markets, it will have to mix that strategy with more traditional product strategies to take it someplace where its existing customers won’t. Jason seems to understand this. His limited expertise in ERP and manufacturing won’t be what takes them there, but listening to his staff and using invested capital wisely very well could.

Its competitors have always underestimated Plex Systems. A word of caution to those competitors… watch out!