As our COO, John Sicard stated:

“With the increasing speed of business, no one can afford to wait to make a decision. Fast and confident action are the table stakes. That means you need to easily uncover areas of concern; do deep analysis; and turn decisions into action quickly. From a technology perspective, these needs translate directly to the areas of focus for this product release.”

In-Memory Computing Performance

• RapidResponse now supports an order of magnitude more memory, supporting terabytes of data and faster performance of analytics.
• The result is a very powerful analytic and reporting engine that can process millions of records of data and perform demanding calculations (such as constrained capacity planning, available to promise, clear to build, and many others) in seconds.

Watch this video from Luc Vezina, vice president of product marketing and product management at Kinaxis on In-Memory Computing Performance:

Advanced Data Visualization

• Users are able to view and interact with data in RapidResponse like never before, with several significant enhancements to the product’s data visualization capabilities.
• The jewel of the data visualization package is a powerful treemap chart that allows users to interpret especially large sets of data in one compact view to quickly locate outliers and areas of concern. This is particularly influential when analyzing gaps in sales and operations plan.

Closed-Loop Integration and Automation

• Even tighter integration of RapidResponse with a company’s legacy enterprise environment is now possible through two-way, high-frequency updates of net changes between ERP and RapidResponse.
• The improved integration to transactional systems ensures companies operating in multi-application environments can work in near real time.

For more information on the RapidResponse Spring 2011 Release, check out our feature highlights page.

If you’re short on time, check out the video below for a preview.

Olympus needed an integrated, global SCM platform to improve its S&OP process, with the specific goals of more efficient new product introductions, as well as tighter alignment of demand and supply overall.  They came to us.  I quote:

“We found that Kinaxis stood alone in terms of the depth and breadth of functionality its solution could offer.”

Wow.  We are humbled.

It’s been a good week for us.  We also just added a new section to our website for executive testimonials and are honored to include some stellar video clips from the CIOs of both Qualcomm and Flextronics. (more clips are coming)  Having a CIO say that RapidResponse is “at the heart” of everything they do…well, it has made our year….and 2011 has just started!

Sure, we can advocate our value… make our case… sing our own praises all we want (and we do!) but at the end of the day, we know that people want to hear it from the customer.  So, let’s do that.

1. Common platform (or may be called Standard Platform):  Most big companies are trying to standardize their IT requirements on one or two “common platforms”.  Typically this means a software platform that has broad functional capabilities that can solve multiple business problems.  If a company had a new business need they would first evaluate whether one of their common platform solutions can meet their requirements prior to evaluating a point solution.  In theory, this should save the company money on integration, hardware and licensing costs.  However the company will likely have to forego some functionality.  If a software vendor can be designated a common platform, then they have a better chance of being more broadly deployed.
2. Technical infrastructure and scalability:  The big ERP vendors have done a very good job marketing their technical infrastructure to ensure very large deployments of software.  They have benchmarking services to prove scalability.  Although these companies are strong on infrastructure and scalability, large customers still have issues with performance on some applications.  It is important for any other software company to be able to address these concerns and compare their solution to the big ERP vendors.
3. Job security:  The employees in an IT department typically want to work with name brand software companies so they can make themselves more marketable.  They don’t want to become experts in a little known software that won’t help them get their next job.  Many CIO’s have staked their careers on implementing their ERP solution and don’t want to admit it cannot meet all their needs.
4. Costs:  Big ERP companies many times “throw in” extra modules in a bundled license agreement with the hope that the customer will sign up for the M&S cost if they use those modules. (see John Westerverld’s recent post about M&S – that’s a whole discussion on its own)  Regardess, the extra “free” modules make any ROI evaluation between software vendors look better for the ERP vendor.  Although, there are typically many “hidden” costs in implementing new modules.  For example, some of the modules actually require a fairly heavy integration effort even though it is on the same platform because they are not native products to the core ERP engine.  Being able to show Total Cost of Ownership and ROI will be important for any software company wanting to compete against the big guys.

In order for a software company to be successful against the big ERP vendors they will need to address these concerns.  Certainly the above concerns can be overcome, but the software vendors should know the bias they are up against.

What reasons have you seen on why companies don’t want to leave their ERP provider to choose a better solution?

“Oracle’s annual maintenance fee combined with the cost of upgrading to Release 12 has become so expensive that we and others opted not to renew support this past year.”

Another indication that ERP support and maintenance costs are a significant issue.  A quick search on Google brings a wealth of articles talking about the cost of ERP ownership;

Is this Highway Robbery or Indentured Servitude?
Oracle Is “The Teflon Don” of ERP Software Maintenance
ERP Software Maintenance: An Offer You Can’t Refuse?
Oracle: Don’t Hate the Player, Hate the Game
ERP Support Drama: How Far Will Oracle Go to Protect Its Golden Egg?
Operations Hangover

There are more, but these give you a good idea as to the state of affairs with ERP support and maintenance. 

An  article by Thomas Wailgum at CIO.com brought this issue into focus.  In this article Wailgum discusses a concept from a Gartner report called ‘Global IT Debt’.  As Gartner defines it, global IT Debt is “the cost of clearing the backlog of maintenance that would be required to bring the corporate applications portfolio to a fully supported current release state”   According to Gartner, the Global IT Debt will total 500 billion in 2010 and has the potential to jump to 1 Trillion by 2015.   The Gartner announcement points out that  the most worrisome issue is that many IT organizations don’t have an application inventory  or a structured application review process which means that IT management isn’t aware of the extent of the problem.

On the one hand, working for a software company, I understand the importance of support and maintenance payments.  This money goes to staffing support call centers, tracking down and fixing bugs and to funding research and development into new capabilities that will ultimately provide additional value to customers.  In our case, however, we provide an on-demand service that includes support and maintenance in the monthly payment.  Of course as a subscription service you incur little upfront costs so the monthly payment seems far more reasonable.

The old ERP model of perpetual, on-premises licensing adds insult to injury by demanding a staggering up-front price and ‘extortion like’ annual support and maintenance costs.  At some point (and it’s starting to happen…) companies are going to say enough is enough and start to look for alternatives. 

So what alternative is there?  The software as a service (SaaS, or on-demand) model is certainly gathering momentum.   When we first introduced our on-demand offering in early 2006, customers would often express great concern over data security and system availability. Today, after years of proven performance and security both with our software and with other SaaS companies like Taleo and Salesforce,  most prospects don’t even ask about on-premise models.

Will Big ERP go on-demand?  They say they are, but a quick look at what they are offering, it appears to be more of an outsourced model  than on-demand. Some companies like NetSuite are delivering ERP for small / medium businesses via SaaS.  My thinking is that companies like this will expand upwards and will start taking some of the large accounts away from SAP and Oracle.  Time will tell.

What are your thoughts on the ERP maintenance agreements?   Are you considering going off support? When is the last time you upgraded?  Comment back and let us know.

The presentation was put on by Ron Stappert, Senior Director of Supply Chain and Devin Taylor, Senior Director of Advanced Planning from Jabil.  Jabil is one of the largest contract manufacturers in the world with 85000 employees in 55 sites around the world.

Jabil bought RapidResponse in 2000 and has 4300 named users that have accessed RapidResponse in the last 12 months.  They have roughly 250 users accessing the system at any one time.  For supply chain software, these numbers are impressive.  The question is, how did Jabil do it?

Ron and Devin identified 3 key factors;

Users get what they need - A user friendly environment; the ability to easily customize views backed with powerful analytics means that users can immediately use the software to get the answers they need.   All Jabil users have the ability to author resources – that is, the ability to create or modify the views that they use.  Most users simply add a column, others however, create complex resources from scratch.

Tools match the process - The tools that were deployed match the processes used.  This helps to ensure that the users can learn the new tools as they learn the process.

User training and functionality - Users are trained and encouraged to modify their views to simplify their tasks. Further, users are allowed to experiment and are given support if they have questions or are confused.  Jabil has “subject matter experts”  within each group who provide support within that group.

Two of these factors have a dependency on the software that you are using. If your system requires 3 weeks of consulting to add a field or change a report, I’m afraid user adoption is going to suffer.  Your software just isn’t agile enough to keep up with today’s changing business processes.  Flexibility and ease of use must be key items on your software selection matrix.

Jabil’s training philosophy is interesting as well.  Devin showed how they created a simple data environment that can quickly be loaded and used to demonstrate key aspects of the software and resources in the context of the problems that users would face day to day.  The scenario started with a simple problem and complexity is added as the new user starts to learn.

Ron and Devin outlined some basic suggestions to improve user adoption;

Develop internal expertise - This is the subject matter expert (SME) that I mentioned earlier.  Ron and Devin went one step further and recommended that if possible, the SME should be retained when workforce reductions occur.  As we have seen, workforce reductions are often followed by workforce increases and SMEs are very useful to train new employees.

Leverage training resources by the vendor – Kinaxis and many other software vendors offer free training in the form of streaming videos that your users can leverage to learn.

Read the Manual - (or as Devin put it….R.T.F.M – Read The Functional Manual ).  This is all about getting new users to help themselves.  Get them used to going to the manual first.  This means that you will have less work supporting them, and they can get the answers they need when you aren’t available.

Look at your systems.  Is user adoption where you want it?  Do you find users going back to the tried and true (like Excel) to do their jobs?  Maybe you need to take a closer look at how your users are trained and the support you give them.  Perhaps there is some potential that you can unleash to drive user adoption to the levels you need.

I frequently tell my implementation team that they need to be very concerned with user adoption and buy-in on the project or else the project will surely fail.  My experience tells me that even if you implement a system that meets exactly the functional goals outlined in the contract but fails to obtain user adoption then the whole system is likely to be scrapped.  So, this post will discuss my thoughts on how to obtain user buy-in and adoption.

My thoughts:

• Have a kick-off meeting  with a broad range of users across the spectrum prior to the formal project kick-off to educate everyone on what the project is, why the company is doing it and most specifically how it will benefit them.  This meeting ideally would be held in person to generate excitement or alternatively through an interactive webinar as it is difficult to get all users in the same room at the same time.  If everyone is global, multiple meetings may have to be held.  I would suggest live meetings over recorded ones so people can ask live questions and get an immediate response.
• The users that are chosen to be “super users” or key users in the project should be people who not only have the requisite functional knowledge to represent their area but also have the respect of the other users they represent.  Sometimes people are assigned to the project because of their deep skill knowledge, but lack respect from others on the team so the other users automatically distance themselves.  The right person should have both functional skills and respect from their peers/colleagues.
• The key project team members should also be empowered and held accountable.  They should be able to represent their area and make decisions for the entire group.  Or if they need to ask others for input, that they do so in a streamlined process that does not drag the project around in circles.  Too many times I have seen people say “here are the requirements” but when additional users test the system, those users identify gaps in the requirements.  The signed off requirements should be the marching orders for the project team.
• A broad spectrum of people need to be involved in the design of the solution being implemented.  Let’s assume we have a global project and we’ve assigned excellent super users from North American on the project however, this project will also impact users in Europe and Latin America.  Ideally someone from Europe and Latin America need to be assigned to represent those regions so the users from those regions feel their voices are heard and buy-into the system being developed.  Do not assume great super users from one region can represent another.
• Super users/key users representing a broader group of users should be communicating regularly to the broader group decisions being made and generally keeping them informed on status of project.
• Users need to be involved in testing. Of course the day to day project team members will unit test the system to ensure requirements are met.  A broader group of users should be brought in for acceptance testing, although they should be carefully prepped so they aren’t trying to broaden scope or add new requirements.  By bringing them into the acceptance testing activity they will not only have a better understanding of the system but they will also feel more involved.
• Effective training is the key and an area not to be skimped on.  Generally it is not a problem for the day-to-day project team members to get training on product, but some companies don’t spend a lot of time focusing on end user training.  Effective (or non-effective as the case may be) end user training can make or break user adoption.
• Communication – again, regular communication on status of the project, timelines, scope, how it will impact them will aid in user adoption.
• Some projects I have been associated with will also perform a parallel run, this can be useful if you are worried about user adoption at go-live and of course mitigate the risk at go-live.
• And lastly leadership, the company leadership needs to be vocal about the benefits of the system and enforce use of the system by their teams.  If the users don’t see leaders involved and stressing the benefits, they may not get on board.

Those are my thoughts, please share your thoughts and experiences as well.

See first post of series here on executive sponsorship.

The WSJ article, From Snowmobiles to Cellphones, a Scramble for Parts, (paid subscription or preview sign-up may be required) further notes that companies have had to reconfigure offered products due to persistent supply shortages. It notes that shortages of transistors, capacitors and integrated circuits became pronounced in the first quarter, and persist in the second quarter. Telefon AB L.M. Ericsson indicated that shortages cost the company $400-$550 million in sales and delayed shipments, and Royal Phillips Electronics, Polaris Industries Inc. Motorola and Whirlpool are also mentioned as being impacted. Motorola CEO Sanjay Jha  summed it best noting that his company is scrambling in a “constrained environment.” Companies utilizing current hard-to-find components are seeking their own fixes which include offering customers different features or alternative components and/or technologies.

While it is obvious why Ericsson, Philips, and Motorola are affected by electronics component shortages, what is interesting is Bob’s inclusion of Polaris and Whirlpool in the list of companies. The original WSJ article clearly focuses on electronic parts shortages. Polaris makes snowmobiles and ATV’s. Whirlpool makes dishwashers, dryers, etc.  What does this have to do with electronic parts?  Well, a lot actually. I remember working on a project at Volkswagen in Germany in the late 1990’s shortly after they had just come out with the Golf Mark IV.  I don’t remember the exact details but the number of chips in the Golf had gone up from about 5 in the Mark III to about 50 in the Mark IV. Yet the demand that this represented for the chip manufacturer was still relatively low compared when compared to the demand from electronics companies such as Ericsson. The difference in the relationship with the more traditional Volkswagen suppliers, who made mechanical components for the Golf, was profound.  Whereas the chip demand represented a lot less than 10% for the chip manufacturer, often the demand from Volkswagen for the mechanical component suppliers represented well in excess of 30%-40%, sometimes in excess of 75% when factoring in aftermarket sales. Clearly Volkswagen had a great deal more leverage with the mechanical component suppliers.

Other industries, such as the white goods industry, will often design different washer or dryer models using virtually the same mechanical components, but use different chips to provide differentiation. Electronic components are everywhere. Delays in component deliveries affect many industries. The original WSJ article contains a graphic showing how the lead time for a common type of transistor has increased from 10 weeks in July 2009 to 20 weeks by February 2010.

Initially I set out to try to estimate the effect of electronic component shortages on G20 gross domestic product, but the more I looked into the data, the more it seems that electronic component shortages might already be “old” news. Clearly there is still a lot of caution in the industry and the effects are very real otherwise neither the WSJ nor Bob would have written about component shortages. It is also something we have been hearing from customers and prospects for the past 6-9 months. Yet some really good results over the past four quarters, such as those from Intel, seem to indicate that the situation may be easing. Since the financial results of semiconductor companies are a leading indicator of how other companies are investing in raw materials, it is encouraging to see the upward trend in both revenue and gross margin reported by Intel. But this blog is about component shortages. While Intel has shown better revenue numbers, the increase in the margin would still indicate a shortage situation. Looking at Intel’s inventory numbers indicates that these have been rising sharply too, especially finished goods.

The question is whether Intel is the proverbial “swallow that does not a summer make.” Looking at public semiconductor companies around the globe would indicate that the same is true throughout the industry. The figure below shows averaged financial results for all semiconductor companies.

This effect is most pronounced when considering the semiconductor companies in Asia, though a similar pattern is observed in North America, and less so in Europe.

Clearly it takes time for inventories to be built across the entire supply chain, but it is encouraging to see the level of inventories being built in the semiconductor industry. Notice that inventory levels far exceed the levels in early 2008.  In addition, the semiconductor industry is only one segment of the overall electronics industry. But, as I noted earlier, the semiconductor industry is a leading indicator because it is far up the supply chain.

What is your experience? Are you beginning to see an easing in the electronic component supply shortages?

Image via Wikipedia

“…They’ve been in existence for decades, they can spread like wildfire, and no one has quite figured out how to stop their proliferation – even if they really, really want to.”

I came across this entertaining rant in the Sourcing innovation blog.  The idea is that despite many attempts on behalf of IT to get key corporate data out of spreadsheets and into dedicated systems, spreadsheets keep coming back. 

The doctor’s post was prompted by an article in CIO.com that indicates that BI vendors have resigned themselves to the fact that spreadsheets are here to stay and have devised means to incorporate spreadsheet data into their systems despite the fact that studies have shown that 80-90% of spreadsheets contain serious errors. You know it’s true…How many times haven’t we been in the situation where user A’s spreadsheet showed different results than user B’s spreadsheet for the same thing?   OK, so there are a few errors…not a big deal, right?  Wrong!  To see the impact spreadsheet errors can have, check out this CIO.com article from a few years ago that outline 8 of the worst spreadsheet blunders to date. Yikes!

So why do people rely so much on spreadsheets?  There are many reasons I’m sure, but the top culprits are as follows;

• The business system (BI, CRM, ERP, etc) can’t present the information the way they need to see it
• The business system doesn’t support what-if modelling
• The business system is too darn hard to use
• The business system logic is fixed and can’t be changed (within a human lifetime)

Until we get enterprise tools that can change these factors, spreadsheets will continue to proliferate regardless of how much bug spray we throw around.

Why do you continue to use spreadsheets?  Do you have any great spreadsheet blunders to share?  (We won’t tell… honest!)

As most who closely follow SAP know, SAP has been talking about in-memory databases for several years. To those that don’t follow the exciting world of database technology, you might even think SAP invented in-memory databases! The truth is that in-memory databases have been around for longer than most realize. Check out this Wikipedia page and you’ll get a sense for the dozens of innovators that led the way well before SAP stepped onto the field. While you won’t see Kinaxis technology mentioned in the mix, we’ve been at it for longer than most—perhaps even the longest. Despite our laser-like focus in this area, our senior architects continue to admit there’s still room for improvement and are in tireless pursuit of it. However, to borrow from the barber’s famous line from one of my favorite Leone spaghetti westerns (“My Name is Nobody”) – they would also state — Faster than ‘us’, Nobody!

While I wasn’t present to witness it, our development of in-memory technology began 25 years ago with a hand full of brilliant engineers in a basement who founded their own company, Cadence Computer. Their goal was simple: to invent something meaningful and technologically amazing. One of our Chief Architects, Jim Crozman, had an idea to run ERP in-memory—motivated by improving upon a then 30-plus hour run. As you might imagine, finding a machine to run the software that was in his head at that time proved to be impossible, so Jim, along with a small group of talented engineers, did the only thing they could think to do: They invented and constructed a specialized computer (the size of two refrigerators), which would become a dedicated in-memory database appliance—likely a world first. They would call it SP1018. We all know how technologists love a good acronym with some numbers attached to it! At that time, 4MB of RAM took an 8×10 circuit card—and wasn’t cheap! They were packaged into modules with a custom bit slice MRP processing engine capable of 10M instructions per second that could process data in memory at its peak speed. Program and temporary working memory were in their own storage blocks, so the main memory space and bandwidth was reserved for the database. Up to 16 of those processing/memory modules were clustered with a high speed backbone to form single MIMD processing system that could do an MRP “what-if” simulation for a large dataset in minutes. We would go on to sell this computer to GE, at that time an IBM 3090 showcase center. The IBM 3090 had a whopping 192MB of RAM, and sitting next to it, our appliance with 384MB of RAM. IBM’s ERP analytics ran in over three hours, while our appliance replicated the same analytics in approximately three minutes.

Computer architecture and speed has evolved greatly since those trailblazing days. Inexpensive multi-core systems with big on-chip caches are capable of tens of billions of instructions per second. No need for custom hardware today! Speaking of on-chip caches, understanding and leveraging this resource has become the key to maximizing speed and throughput. Memory architecture remains 10 times slower than processor speed, so understanding how machines retrieve data and the treatment of that data within the core is fundamental to in-memory database design. It takes the same amount of time to retrieve 1 byte of data as it does 1 block of data. This makes locality of reference a very important system design criteria, minimizing memory access cycles to get the data you need for processing. Data organization and keeping data in a compact form (e.g. eliminating duplication) and with optimal direct relationships and clustering makes for optimal processing speed (minimize memory access cycles).

At this year’s SAPPHIRE Conference, SAP explained how it has chosen a hybrid row/column orientation as the construct to store in-memory relational data. Indeed, columnar orientation helps with data locality and compaction of a column of data (obvious), and is most effective in circumstances where the use cases are driven by querying and reporting against a database that does not change or grow rapidly or often. Dennis Moore says it best in his recent blog:

“There are many limitations to a columnar main-memory database when used in update-intensive applications. Many SAP applications are update-intensive. There are techniques that can be used to make a hybrid database combining columnar approach for reading with a row-oriented approach for updates, using a synchronization method to move data from row to column, but that introduces latency between writing and reading, plus it requires a lot of CPU and memory to support the hybrid approach and all the processing between them.”

The challenges associated with columnar orientation will be felt most when attempting to drive performance of complex in-memory analytics. By analytics, I don’t mean complicated SQL statements, compound or otherwise. Rather, I refer to compute-intensive specialized functions, like ATP/CTP, netting, etc. That is calculating consequence to input events based upon a model of the business, particularly the supply chain. Columnar organization solves issues for a small subset of problems but makes most usages of the data much worse. Processing usually involves a significant subset of the fields on a small related set of records at a time. Since a single record’s data is spread across different areas of memory by a columnar organization, it causes a bottleneck between memory->cache->processor. A single processor cache line ends up with a single piece of useful information and multiple cache lines are then needed to get just one record’s data. For example, ATP for a single order needs a subset of demand, supply, order policies, constraints, BOMs, allocations, inventory, etc. Perhaps this is the main reason why the PhD students at the Hasso Plattner Institute of Design at Stanford reported only achieving a 10x improvement for their ATP analytic prototype using HassoDB, significantly slower than their raw query performance ratios.

Millisecond query results are at most half of the equation—and definitely the easiest half. Don’t get me wrong, faster BI reports are great. If you’ve been waiting a few minutes for a report, and you can now get it in seconds, that’s real value. The trick is to go beyond “what is” and “what was” analysis, and add “what will be if” analysis. If done correctly, in-memory analytics can achieve astounding speeds as well. For example, the Kinaxis in-memory engine processes analytics (e.g. ATP), from a standing start (worst-case scenario) with datasets consisting of 1 million part records, generating 2 million planned order recommendations following the creation and processing of 27 million dependent demand records in 37 seconds, while handicapping the processor to a single core. Further, eight different users can simultaneously request the same complete calculations on eight what-if scenarios of the data and still get their independent answers in less than 60 seconds. No need for ”version copy commands.” My personal favorite performance test done in our labs involves proving that the more users logged into to the system, the less time it takes for them to receive their results (i.e. average time per request goes down). As impressive as these benchmarking numbers are, these tests do not represent typical user interaction (i.e. batching full spectrum analytic runs). If done correctly, massive in-memory databases with intensely complex analytics can scale to thousands of users on a single instance (think TCO here), each capable of running their own simulations—change anything, anytime, and simultaneously compare the results of multiple scenarios in seconds.    

RapidResponse simultaneously measuring eight scenarios for a user using weighted scorecard

All this speed and scale becomes valuable when businesses can bring about new and improved processes capable of delivering breakthrough performance improvements. With collaboration gaining traction as the new supply chain optimizer, companies are driving innovation toward this area and testing in-memory databases in new ways. For example, not only is it important to monitor changes in the supply chain and the potential risk/opportunity they create, companies now want to know “who” is impacted, “who” needs to know, and “who” needs to collaborate. While this seems like an obvious value proposition, the science involved in delivering this on a real-time basis is staggering.

I’m happy to see SAP draw such attention to the merits of in-memory databases. It serves to validate 25 years of our heritage, our focused research and development, and surely validates the investments made by some of SAP’s largest customers (Honeywell, Jabil, Raytheon, Lockheed Martin, RIM, Nikon, Flextronics, Deere, and many more) to leverage RapidResponse. Whether related to Sales and Operations Planning, Demand Management, Constrained Supply Allocation, Multi-Enterprise Supply Chain Modeling, Clear-to-Build, Inventory Liability Reduction, What-if Simulation, Engineering Change Management, etc., these great companies are experiencing and benefiting from the speed of in-memory technology today.

Why wait?