My First Encounter with Shadow IT

In my recent post on what I learned about enterprise IT at Smith Tool, I mentioned that I needed another few posts to cover some of the more interesting lessons learned. I already covered what I learned from a failed waterfall development project in 1980. But the lessons kept coming, shortly thereafter, in my first encounter with “shadow IT.” 

Shadow IT commonly refers to information systems that are purchased or developed apart from the corporate IT department. 

An Inventory System for Tooling

In 1981, I got a new assignment: to develop a system to manage inventory of perishable tooling in the manufacturing plant [1]. Our manufacturing systems, some of which I had developed, did a fairly good job of managing inventory of direct material—raw materials and parts that went directly into the finished product. But they did not yet fully manage the inventories of tooling that were needed to make those parts, such as cutting tools and grinding wheels. Managing tool inventory was important, because a stock-out of tooling could delay a production order just as much as a stock-out of direct material could. 

We had already built systems to maintain tooling bills of material (tool lists) and to associate those tool lists to production orders. We had also built a system to track tool usage on production orders. But we had not yet closed the loop to track on-hand inventory of tooling and to plan for replenishment based on production plans. The existing manual system was nothing more than an intricate paper-based min/max system that required a physical inventory count three times a day! Expediting to cover shortages of tooling was a way of life. As a result, my analysis showed that 90% of manufacturing production order delays were the result of tooling being unavailable. The benefits of an automated system would be huge [2]. 

Some perishable tooling items were purchased. The rest were fabricated in Smith’s own tool-making shop or subcontracted to outside tool makers. The tool room was, in essence, a factory within a factory, and it would ultimately require a manufacturing planning and control system linked to the main MRP system at Smith Tool. This is a key point in the lesson learned to come. 

A Startling Discovery

My first step was to take a walk out to the tool crib to meet with the Manager of Tool Control (“Fred”), gather some data, and talk to him about his requirements. The conversation, as I recall it, went something like this. 

Me: “Hi Fred, as you may have heard, we’re starting to gather requirements for a new Tooling Inventory System to replace your manual system.” 

Fred: “Oh, no need to do that, we’re going to install the computer system that they’re using over in the San Bernardino plant.” 

Me: “Wait, what?” 

Fred: “Yeah, the guys over in San Bernardino didn’t want to duplicate our manual system, so one of the NC programmers put together a system on one of those TRS-80 computers you can get at RadioShack[3]. It only took him a few weeks to program it.”

Me: “Fred, wait a minute. I’m not out here setting up my own tool room. So, you guys shouldn’t be setting up your own computer system. That's my department.” 

After this, I managed to calm down and got a walk through to see the tool crib operations and to gather some sample documents. 

When I returned to the IT department, I went straight to Rodger’s office to tell him what happened. He told me that I’d better take the 90-minute drive out to San Bernardino to see this rogue TRS-80 system. 

Evaluating the Shadow IT System

The IBM PC would be on the market in just a few months (August, 1981), opening the floodgates to what would later be called end-user computing. But this was my first encounter. What stunned me the most was not just that my users had usurped my job of systems development but that they appeared to have done in a few weeks what we had planned to do in a six month effort. However, as I would soon learn, the scope of what they had done on the TRS-80 fell far short of what we were planning to do on the mainframe. 

The first thing I saw involved limitations of the TRS-80 hardware as a business computing platform [4].  These were easy observations. But, as we all know, personal computers would soon overcome those limitations and become a real disruption to mainframe computers.

My more strategic observation, however, was that the TRS-80 system only addressed a single need in what should be a closed-loop end-to-end process for managing tooling. There were no tooling bills-of-material (tool lists), no tracking of tool usage, no association of tool lists to production orders (at multiple revision levels), and no determination of tooling demand based on planned or released production orders—all functionality that we had already built or were about build on the mainframe system. I concluded: 

The TRS-80 system in use now by San Bernardino Tool Control basically serves their need for the maintenance of inventory data. It is a simple alternative to the card file used by Irvine Tool Control for this data. However, the long-range use of the TRS-80 has serious limitations as outlined above.

Beginning of a Major Disruption in Enterprise IT

Although I didn't realize it at the time, the world of corporate IT was changing. In reviewing an early version of this post, my manager, Rodger Beard, offered this analysis (lightly edited). 

Our Smith Tool TRS-80 experience demonstrated a trend that was already unfolding regarding the nature of business computing.  Dramatically cheaper computing hardware and operating system software had already started to come on scene with the introduction of mini-computers, from DEC and HP especially. But the TRS-80 and IBM's hurried, clumsy, poorly conceived PC initiative soon after had a far, far bigger impact.  Mini- and micro-computers enabled the rapid movement away from the IBM computing castles that were then the norm, with budgets that only kings could afford.  Because the dollars were so great and castles took so long to build (with high implementation costs and high risk of failure) there was a critical business need for better and cheaper ways to deploy automated business systems.  The TRS-80 and then PCs offered a way to fulfill that need, and to work around IT departments that were mostly seen as being in the way.

That said, low-cost hardware was just the first leg of a 3-legged stool of disruptive technological innovations that would become manifest over the coming years. The second leg was the faster development time that these platforms offered to build business software.  The TRS-80s at Smith Tool clearly demonstrated that software could be developed more cheaply, faster, and more easily, albeit with certain downsides that we, the knights guarding the IT castle, thought were important, but not as important to many in the business. 

The point is that shadow IT was conceived as the direct solution to an already very well known problem. There was too high a cost, as well as too much delay and pent-up demand for business software.  Packaged software suites, higher level and advanced programming languages, 4GLs like Focus,  emerging SDMs, software engineering and coding being taught in public schools, software training as a industry, computer engineering majors offered on every college campus, H1b visas, outsourcing, and then offshoring, all were solutions intended to solve this problem.  Net of it all, software cost is now tiny compared to when we found out about the TRS-80..

The third leg of the new stool was obviously overcoming the primitive data communications networks of the time as well as costs and delays associated with creating node-to-node communications.  The creation of the internet, and with it fast, cheap, available connectivity was the disruptive change that gave the new IT stool all three legs. (Wow did it ever!)

Lesson Learned: Bring Shadow IT out of the Shadows

Rodger is right. Although my analysis of the TRS-80 system may have been correct in identifying its shortcomings, it took me a few more years to understand the bigger picture. When the business has a need and the corporate IT organization does not have the resources to meet that need, the business will find a way to solve the problem. The days when the IT organization could just say no, or wait until next year, were coming to an end. 

Ultimately, the technology disruption brought its own new set of challenges. For example, user departments purchasing or building their own software, were soon asking for the IT organization to connect them to corporate systems. Many IT leaders were understandably distraught with these requests when they were not involved in the original development or procurement of the shadow system.   

 

Over the years, the most healthy way to deal with shadow IT is to bring it out of the shadows. It is really a matter of IT governance. Best practices in dealing with shadow IT include having a multi-year IT strategic plan that addresses major needs throughout the organization, guidelines to determine which systems are best deployed by corporate IT and which can be left to end-user development, an overall enterprise architecture, and budgetary flexibility where in some cases the business funds new system development, with the IT organization delivering or managing the services. 

Postscript: My recollection is fuzzy concerning the events that followed. My personnel file indicates I finished implementing the corporate tooling inventory system in 1982, and I moved on to an even more interesting project. But this all took place just before the multi-year decline in oil prices and collapse in the US drilling rig count, which devastated Smith’s business. The San Bernardino plant was shut down, so the use of the TRS-80 system became moot. 

End Notes

[1] In reviewing the system specification I wrote for this project, I notice that I applied the lesson learned from my previous project, where we had a failure with the traditional waterfall development approach. In my system specification for this project, I wrote: 

“Because a project addressing all the known requirements for a tooling inventory system would take over one calendar year to develop, we have adopted a two-phase approach. This allows Manufacturing Services to receive benefits from the project within six months of product initiation. It also allows us to evaluate the use and effectiveness of the system delivered in the first phase before beginning the second." [Emphasis added.] 

In other words, I was determined to test the users’ commitment to adopt initial capabilities of the new system before IT would spend the time and effort to develop the rest of it.

[2] When I started writing this post, I assumed that tooling inventory control systems would be commonplace today as modules within manufacturing ERP systems. Although SAP appears to have a solution, I am hard-pressed to find many others, outside of a few point solutions. I have a feeling that many customers today manage tooling inventory as a special item type in the production bill of material, which may be adequate for many manufacturers, although this approach has its shortcomings. If readers have insights on this, please leave a comment on this post. 

[3] RadioShack, founded in 1921, was a one-stop shop for all things electronic, from components to personal electronics to micro-computers. It essentially went out of business in 2015. The TRS-80, launched in 1977, was one of the first widely available microcomputers. 

[4] As I wrote in my trip report, 

“The TRS-80 is a microprocessor, and it is not designed for large-scale business systems. It has limitations on file sizes and key lengths…. There are limitations in real storage…. The hardware is designed to be run only 8-10 hours a day. It is designed for the occasional hobbyist or for a light back-office business, not for the day-to-day operation of a heavy manufacturer.” 

Moreover, the user-developed tooling system was only intended to satisfy needs around tooling procurement and inventory control. There was no functionality for tooling bills of material (tool lists) or ability to associate them with production orders. In Irvine, we had already built a system to automate these functions on the mainframe, but San Bernardino de-automated those functions and put them back onto a paper-based system. 

Image Credit 

TRS-80. Attribution: Blake Patterson. Source: Wikipedia Commons.

What I Learned from a Waterfall Project Failure

In my most recent post on lessons learned in my career, I covered my time as an IT employee at Smith Tool. I learned so much in those years, and I need another few posts to cover some of the more interesting lessons.

By 1980, my work in manufacturing systems had been all in machining operations. Now Rodger gave me a new assignment, to develop a new system to support Smith’s forge plant. This opportunity took me upstream into the forge, which I was told was the largest forge in the United States west of the Mississippi¹.

As I noted in the previous post, I loved the nitty-gritty sights and sounds of the metalworking plant. But the forge was another whole level of physicality, almost violent. As you approached the forge, you could hear the hammer and feel the ground shake as the press hammered out parts². And outside the plant were pallets of newly forged parts, still red hot to the point where you could not stand closer than 20 or 30 yards without feeling the heat.

Here is a good video of a forge plant that gives a sense for what it’s like to be inside one. The press in this video is smaller than the two at Smith. Also, our forge plant was more modern and the parts being forged in the video are different, but the sights and sounds are the same.

Forging Operations Are Tricky to Schedule

Smith used a process called closed die forging. This means that the red-hot steel bar would be pressed into a die in the shape of the finished part. The tricky part is that the die would only be able to produce a given number of forgings before it had to be sent out for “resinking,” a sharpening operation, so that they could produce more forgings. The production scheduler used manual log books to keep track of how much life was left in each die and to know which dies had enough life left to fill an order. But if the log books were not updated correctly, the forge might not be able to meet its production schedule. This was the process the new system would automate, with the benefits of being able to better meet production schedules.

The new system was described in a company newsletter after the project was (supposedly) completed.

Simply stated, the Forge Die Tracking System keeps track of over 3,000 components that make up the 300 forge dies used to stamp out the various forgings to make Smith Tool’s products. Additionally, the system makes the die selections to fill each forge order according to which dies most closely match in wear and on the basis of how much life the dies have left. When the system notes that a die’s life is getting low, it will suggest to the scheduler that the die be used to make as many forging as is left in it to make, and then be sent out for resinking. So, while the order is being filled, the excess forgings being produced will go into inventory as safety stock.

I was assigned as project manager and lead analyst six months into the project, which had stalled for lack of someone who could develop the calculations for picking the best set of dies for a given order, suggesting the optimum production quantity to “run out” the die, and to track dies sent out for resinking.

I took it as a challenge. I remember distinctly that this was taking place during the run up to the US 1980 presidential election. So, I wrote my programming specifications with references to identifying candidate dies, nominating them, and then electing the best one. Although I had three programmers reporting to me for this project, I wrote some of that core scheduling logic myself.

The New System Installed but Not Implemented

So, what went wrong? There is a little hint of the problem in the final paragraph of that newsletter story on the project:

All the die structures will be on the system by the end of November. The history of all those components will be on by mid-December. The Forge personnel are enthusiastically anticipating the ease and efficiency the system will bring to the Forge operation. [Emphasis added]

Note the future tense.

Here’s how it went down. We put the system into production, and each week I would follow up with the director of forge operations to see how they were coming along with loading the die information. He had assigned this job to his administrative assistant, but the director told me she was too busy to get to it. After several weeks of follow up, it was clear that they had no intention of loading the master file data that the system would need to start scheduling the forge. The system became a very expensive piece of shelfware. I don’t recall how long they let the system continue to run in production without any data to process. But I was soon assigned to another development project.

So, how did this project get approved in the first place? Later I found out that the forge director felt the IT department was spending all its time developing systems for the machining plant, and that it was “his turn” for a new system. The IT steering committee complied.

Lesson Learned: Test User Commitment through Phased Implementation. This was my first real experience with the drawbacks of a waterfall development approach, where you define all the requirements up front, then design the entire system, then program it, test it, and deploy it. In this case, the users were happy to meet with us to provide their requirements and review our system design. But in terms of actually doing any real work, the users were off the hook until we put the system into production. At that point, they were not willing to let a low-level administrative assistant spend the time to do the necessary data entry, or hire a temp worker to backfill her regular duties so she could do so.

After that I vowed never again. What we should have done is build the database and then have the users enter the master file data before we invested more time programming the scheduling logic—the really difficult part, where the bulk of the development hours would go. That would have tested the users’ commitment and saved several months of wasted effort. This was 20 years before the Agile Manifesto, but my software engineering courses at UCI had already taught me about Barry Boehm’s spiral development methodology, which in many ways anticipated Agile. If only I had the foresight and permission to take this approach.

Postscript: In reviewing a draft of this post, the department manager at the time, Rodger Beard, has further recollections. He writes (lightly edited):

I felt at the time and actually still feel a sense of personal failure for allowing this project to unfold the way it did. Exactly the way you've described. A painful recognition, over many months, that good work was being completely wasted.

This was my first experience with having pure politics result in a significant waste of IT resources. However, like you, I learned from it. An aside, at the time, I also felt this system was not well conceived. If it were well deployed, it could have had an excellent ROI. But with the caveat that additional, easy-to-avoid ongoing human capital investment would be necessary to make it pay off. A red flag really.

I think you're spot on regarding how the requirement should have been addressed. This was definitely mine (especially) as well as [name withheld]’s leadership error. We knew it was an "it's my turn" situation. [Our leaders] had decided to throw the forge a bone to shut up the forge director. If only I had had the foresight to ask you to do what your article says should have been done. Sigh.

Thanks again, Rodger, for your confirmation in this series.   

---

End Notes

¹The forge was about 200 yards from the Smith Tool metalworking on Von Karmen Avenue in what used to be known as the Irvine Industrial Complex. Driving through that area today, now known as the Irvine Business Complex, it’s hard to believe there was such heavy manufacturing there into the 1980s. That part of Irvine is now mostly commercial offices and some distribution or light manufacturing facilities. The metalworking plant today is an Amazon distribution center. 

²The purpose of forging is to form the raw material into a part that has dimensions close to what is needed so that the first machining operation only needs to remove a minimum amount of metal. Forging also improves the metallurgical properties of the material. It is the same process as the ancient blacksmith employed with his hammer to make metal implements, such as horseshoes. In fact, Smith Tool began as a blacksmith shop in 1902 in Whittier, CA.

Photo Credit

Waterfall. The original uploader was PaulHoadley at English Wikipedia., CC BY-SA 2.5, via Wikimedia Commons

Manufacturing Is a Huge Opportunity for Cloud ERP

In many markets for enterprise software, the battle between cloud and on-premises (or hosted) systems is over. Salesforce, the market leader in CRM, will soon pass the $10 billion mark in annual revenue. Workday, with its cloud HCM offering and growing financial management applications, expects to hit the $2 billion mark in 2018. Traditional Tier I providers, SAP and Oracle, are certainly not out of the race. But the only way they have been able to compete is by building, or buying, their own cloud services for CRM and HCM. Cloud has won.

Nevertheless, there is no cloud ERP provider the size of Salesforce or Workday, and there is certainly no cloud ERP provider for the manufacturing industry with that scale. NetSuite was founded in 1998, around the same time as Salesforce. But it only reached the $741 million revenue mark in 2015, before being acquired by Oracle. Claiming more than 30,000 companies, organizations, and subsidiaries in more than 100 countries as customers, it is by far the largest cloud ERP provider. Although it has done very well with professional services firms, software companies, and other services-related businesses, manufacturing companies form only a small part of that number. Plex Systems has a pure cloud ERP system for manufacturers dating from 2000 and has been rapidly growing over the past four or five years. But its customer count is under 600. After NetSuite and Plex, the number falls significantly: Cloud-only systems such as SAP’s Business ByDesign, Rootstock, and Kenandy,  each have even fewer manufacturing customers.

To understand how great the market opportunity is for cloud ERP in manufacturing, consider that, according to the U.S. Census, there were about 63,000 manufacturing firms in the United States in 2014 with 20 or more employees, as shown in Figure 1. Considering that the estimated customer counts by vendor in the preceding paragraph include customers outside of the U.S.,  it is safe to say that manufacturing cloud ERP probably has less than 2% market share in the U.S. The market opportunity going forward, therefore, is enormous.

Read the rest of this post on the Strativa blog: Manufacturing Is a Huge Opportunity for Cloud ERP

NetSuite Manufacturing: Right Direction, Long Road Ahead

As one of the first cloud ERP providers, NetSuite is looking to grow its customer base across multiple industries and up-market to larger customers. Those efforts include NetSuite’s renewed focus on the manufacturing sector, as unveiled at NetSuite’s annual user conference, which I attended this week.

Bottom Line: NetSuite is making the right decision and good progress to build out manufacturing functionality as part of its core system, but there is still much work to be done to achieve functional parity with other cloud and on-premises solutions in the marketplace. Nevertheless, the rapid development capabilities of NetSuite's platform offer hope that it will get there quickly.

From Partner Solutions to a Core Offering

Until recently, NetSuite’s approach to serving manufacturers was to provide what it called “light manufacturing,” coupled with customer-specific customizations, supplemented by partner solutions such as Rootstock when heavier manufacturing functionality was required. But this approach could only take NetSuite only so far.

• Support for manufacturers is essential in light of NetSuite’s product strategy. As explained by Zach Nelson in a small group briefing, the customer order is central entity in NetSuite, and NetSuite wants to “own” anything that is input into, or output from, the customer order. In the manufacturing sector, this would include production work orders. It makes no sense, therefore, for NetSuite to hand off these business processes to partners.
• At the same time, the manufacturing sector represents a large potential market for NetSuite. There are more manufacturing companies—especially small manufacturers—in the US than in any other sector. Inadequately serving such a large potential market made no sense as NetSuite looked to accelerate its growth.
• However, some basic features for manufacturers have been missing. For example, standard costing were not addressed in the core product, and few prospects would be willing to customize their implementations for such a fundamental need.

As a result of this realization, NetSuite in 2011 began work in earnest to build out its manufacturing functionality. In a briefing during NetSuite's conference I met the key players hired for this mission. They include:

• Roman Bukary, Head of Manufacturing and Distribution Industries. Roman previously worked for SAP, Baan, and other software companies. Earlier in his career, he was a manufacturing engineer.
• Ranga Bodla, Director, Industry Marketing. Ranga held product management positions at SAP and Pilot Software.
• Thad Johnson, Sr. Product Manager for Wholesale Distribution and Manufacturing Verticals. Earlier in his career, Thad was a product manager at QAD and also held several materials management positions in industry.
• Frank Vettese, Practice Manager. Frank has manufacturing software experience with IFS and Effective Management Systems.
• Gavin Davidson, Vertical Market Expert, Manufacturing. Gavin’s experience includes implementation work with manufacturing systems from Baan, Epicor, Microsoft Dynamics, and Visual.

I’m pointing out the experience of these individuals to show that NetSuite’s push into manufacturing is more than a marketing campaign. It has put together a serious team of individuals to lead the product development effort for this vertical.

An Expanding Footprint

In terms of manufacturing methods, NetSuite is primarily targeting discrete manufacturers although it intends to provide some support for process manufacturing down the road. An ideal prospect would be a discrete manufacturer that does a mix of in-house and contract production.

Let’s take a look at some of the manufacturing functionality that NetSuite has recently added or will be adding. From these few points we can get a sense for where NetSuite is in its current and near-term ability to better support manufacturing customers.

• Standard costing. As mentioned above, the lack of this capability in the past was a showstopper for many manufacturing prospects. But NetSuite reports that it added this capability in 2011, along with standard cost rollups.
• Bills of material. NetSuite has had BOM capabilities for some time, and it will soon support revision levels on BOMs along with effectivity dates. Users can also set a default scrap percentage on BOM components. Support for alternate BOMs is not in the roadmap.
• Routings. NetSuite added production routings to the standard system in 2011. These, of course, are used to create production work orders. Alternate routings will not be provided. .
• Cycle counting. Standard NetSuite code will now support cycle counting of inventory by ABC code.
• Material Requirements Planning (MRP). NetSuite now does a BOM explosion, but it does not generate reschedule messages for purchase orders or production work orders. Neither does it support all types of lot-sizing methods.
• Unit of measure conversions for purchasing, receiving, and inventory management have been part of the standard system for some time.
• Multi-facility planning. It appears that NetSuite will allow customers to maintain separate material plans for multiple facilities while still providing a global view of inventory. If so, this would go beyond what is typically offered in most Tier III on-premises manufacturing systems.
• Labor reporting. The team demonstrated a basic clock-in, clock out process using a tablet computer that can be used to report production completions and labor from the shop floor. This capability is currently in proof-of-concept.
• Capacity Planning will be supported, based on the NetSuite’s “demand plan,” but it does not appear that it will highlight capacity constraints as it will not track available work center capacity.
• Inventory Allocations and Available-to-Promise (ATP). This basic capability—to allocate available inventory and scheduled receipts against customer orders, and to provide visibility into projected inventory availability—is also scheduled as part of standard NetSuite functionality. (Kudos to NetSuite CTO Evan Goldberg for providing a layman’s explanation of ATP during his keynote.)
• Lot and serial number traceability. The team claims capabilities in tracing lot numbers and serial numbers from receipt through production into finished goods. I did not have a chance to verify this functionality, but if present, it would be of interest for a number of manufacturing sub-sectors such as high tech electronics and medical devices.

I believe that NetSuite means business in pursuing the manufacturing sector. However, as can be seen, many of these capabilities (e.g. routings, cycle counting, labor reporting) are very basic manufacturing requirements, things that have been present in systems such as ManMan, AMAPS, BPCS, and others back into the 1980s. Furthermore, some of the planned capabilities will lack key things that a manufacturing prospect would expect. For example, the team characterized NetSuite’s material planning system as a “lean manufacturing system,” which to me is a polite way of saying, “minimal.”

Contrast this with NetSuite’s current capabilities and roadmap for eCommerce (SuiteCommerce) or support for back-office processes of software vendors, which go far beyond what most other ERP providers offer.

Now, it may be that the major opportunities for NetSuite will not be in the hard-core job shops or industrial manufacturing companies. Inasmuch as many manufacturing companies in the United States and elsewhere in the world are outsourcing much of their heavy production processes, it might be that the feature set in NetSuite’s roadmap will be enough to satisfy the majority of its target manufacturing market.

The Time and Place for Customization

One thing that I do not think will satisfy such prospects, however, is the use of customization to fill basic functionality gaps. NetSuite promotes its ability to augment its standard processing with customer-developed or partner-developed customizations, without modifying standard NetSuite code. During his keynote, Evan Goldberg gave an impressive demonstration of the latest version of NetSuite’s development platform, SuiteCloud. I continue to be impressed with the ease-of-use that providers such as NetSuite and Salesforce.com are delivering with their Platform-as-a-Service offerings.

However, the ability to customize and extend the solution should not be taken as an excuse for not offering expected features/functions in the standard product. When prospects need full-blown work center capacity planning, for example, the last thing they want to hear is, “Oh, we can use SuiteCloud to build whatever you need.” For customer-unique requirements, SuiteCloud is a powerful attraction. For what should be standard functionality, no.

Rapid Progress Possible

I’m encouraged by NetSuite’s renewed interest in serving the needs of the manufacturing sector. However the feature set currently in the roadmap does not go as far as I would like to see in building comprehensive functionality for manufacturers. Nevertheless, I believe NetSuite will see success with its product strategy for two reasons. First, as mentioned earlier, it may be that a comprehensive footprint is really not needed to serve the majority of prospects. Second, NetSuite’s cloud platform—like other PaaS systems—offers a rapid development environment. NetSuite will certainly make more rapid progress in filling out its feature set than it would if it were a traditional on-premises vendor.

Compared to the services industries, the number of cloud ERP providers for manufacturers has been limited. But with NetSuite’s renewed focus, the list is now getting a little longer.

Disclosure: NetSuite paid for my travel expenses for its user conference in San Francisco

Related Posts

NetSuite a Viable Alternative for SAP Customers
Key success factor for SaaS suites: functional parity
Kenandy: A New Cloud ERP Provider Emerges from Stealth Mode
The Simplicity and Agility of Zero-Upgrades in Cloud ERP