What we are most proud of is that this is a customer-driven award – multiple nominations from our customers is what landed us on the list. We are humbled.  A very warm thank you to everyone who submitted on our behalf- whoever you may be!

You can check out the entire listing here.

And while you’re on their site…

…check out a great video called, “S&OP: What’s It Really About?” featuring Trevor Miles, director of thought leadership here at Kinaxis. In this video (free registration required to view) Trevor provides his thoughts on why so many companies seem stuck in the early stages with their S&OP efforts, and how they can move up the maturity curve to realize significant performance breakthroughs.

The same keynote also described the foundation that today’s supply chains are built on. In particular, there were two analogies that stood out and challenged the audience to think about their own supply chains. The first analogy was having your supply chain foundation built on technology that resembles that of a “picket fence.” In this case, there are gaps where key information may “slip through the cracks” and it becomes difficult to do any meaningful supply chain analysis. If you use Excel this may sound familiar. Supply chain analysis is difficult because those that need to participate are looking at different data, missing data, and there are gaps in the analytics. If your supply chain analytics are built around Excel spreadsheets then you may be bound by the “picket fence.” Excel may be sufficient in an environment where there is little “VUCA,” but when managing today’s supply chain challenges, Excel is not a scalable solution.

The second analogy of interest used to describe the technology a supply chain foundation may be built on was that of “bricks and mortar.” In this case, the analytics required to respond to “VUCA” are just not flexible enough. Old processes that are cast in stone, long analytic run times, and user interfaces that are far from being user friendly are just a few reasons to describe this technology as “bricks and mortar.” If you are trying to get your supply chain analytics from your ERP system, which for the most part is the transaction system, this may sound familiar. In keeping with the analogy it would be like getting blood from a stone. This is the reason many people continue to turn to Excel for supply chain analytics but soon run into the “picket fence” problems.

This is where the “T” in VUCAT comes from, Technology that does not support today’s “VUCA”.

So what is one to do with “VUCAT”? Some analysts were talking about “best of breed.” This may mean abandoning your Excel spreadsheets or getting rid of ERP components that are either difficult to deploy or are not doing the job. In these cases “VUCAT” is actually a verb. For example, if somebody asks, “What are we going to do with all these Excel spreadsheets?” You might say, “We just have to VUCAT and replace them.”  Look for this new word in the next APICS dictionary

If you are going to replace the “picket fences” or “bricks and mortar,” what characteristics will allow you to manage “VUCA”? Here are three key requirements for today’s supply chain analytics;

• “Know sooner” by being able to continuously monitor plan versus actual and alert participants not only of the event but of the consequences.
• “Collaborate now” by automatically identifying not only the consequences of change but those individuals impacted by it and thtat can contribute to its resolution.
• “Respond immediately” by evaluating any number of resolution scenarios in seconds with anyone in any place and compare alternative actions against operational and financial metrics.

This means you can embrace “VUCA” and create a competitive advantage by being a “first mover.”

Did you hear the term “VUCA” used at the Gartner conference or anywhere else? What is your take? Is it a new more descriptive term for today’s supply chain or more of the same?

• Quick start to deployment
• Ease of maintenance
• Predictable Total Cost of Ownership (TCO)
• Faster Return on Investment (ROI)
• Shorter deployment time
• No upfront infrastructure costs
• Better use of internal IT resources
• Service Level Agreements
• Etc.

Since I run the professional services team, I see firsthand how the implementation of SaaS shortens the deployment time.  The first way is creating a software instance(s) for the customer -with SaaS this can be done in hours not weeks.  There is no lengthy wait to procure hardware only to find out it wasn’t sized appropriately and no waiting weeks for a software installer to come onsite to spend days if not multiple weeks (for many ERP vendors) installing software on your hardware.  Instances are created almost instantly as the hardware is already available.  This means an implementation can almost start the next day versus waiting 1-3 months from signing up with a software vendor to beginning a deployment project.

There is also global user availability instantly as there is no “roll-out” of software to sites -just an internet connection required.  Imagine all your users around the globe having access in day one.  This is a huge timesaver in our global world.

In my previous life with on-premises software there was also a lag time during deployment because the customer’s IT department needed to be trained on how to administer the software.  With SaaS, this obviously goes away and eliminates any lag time on the project due to learning curve of the IT staff.  The system is already being administered by experts.

Many times during deployment projects, patches or fixes may need to be applied. This seemingly simple activity could delay an on-premises activity as the IT administrator struggled with learning how to do this.  With SaaS this task, and all upgrades, are being performed by the experts and thus the process is typically invisible to the project team.  Software fixes and upgrades go in without notice and impact to the project.

The Service Level Agreements with a SaaS vendor typically guarantee there will be no system downtime. This is very beneficial during a deployment project as there is almost a guarantee that system downtime will not delay the project.

And last, but not least, most deployments of SaaS software do not involve hours and weeks of customization.  Most customers choose SaaS to take advantage of the out of the box functionality and best business practices built into the software, so the deployments are inherently quicker.

For a little humor on this topic, check out this week’s ‘New Kinexions’ episode on Quick Deployment. In this episode Ari Cole is very behind on his promise ‘deployment time.’

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?

There is an interesting debate taking place amongst the commentators of IT trends and enterprise applications, particularly ERP and supply chain management applications, about the suitability and adoption of cloud or software-as-a-service (SaaS) solution to this space.  This is exemplified by the article from Todd Morrison at SearchSap.com that appeared on Dec 01, ’10 in which contrasts opinions by Liz Herbert of Forrester and Ray Wang, principal analyst and CEO of Constellation Research Group.  This debate is nothing new in that it has been raging since the advent of SaaS some years ago.

On the one side Forrester repeats the usual arguments against broad adoption of SaaS for enterprise applications, which, according the article with my emphasis, state that:

Organizations can also benefit from the Software as a Service (Saas) products that complement the core SAP applications they’re running, according to Forrester.
…  In addition, some organizations are also reluctant to put mission-critical operations, such as supply chain management workloads, into the cloud.

Ray Wang, on the other hand is quoted as stating that…

what’s holding back the adoption of SAP’s on-demand/SaaS offerings is a “lack of ease of use” and cutting-edge functionality such as offered by Kinaxis and Plex.

Liz Herbert’s opinion is these applications…

don’t offer the breadth of capabilities that SAP does and that companies are reluctant to deploy software from Plex and Kinaxis because they don’t have the established reputation that SAP does, and certain functions like SCM don’t lend themselves to on-demand applications.

There is no doubt that SAP has a much greater market share than Kinaxis, but I challenge anyone to call on our customers to evaluate our ‘established reputation’.  And these customers include the likes of RIM, Flextronics, Lockheed Martin, and Amgen, all of whom use an SAP ERP backbone.

And, by the way, they are all very large multi-billion dollar companies with operations around the world.  I state this because the other usual pushback against the adoption of enterprise on-demand solution is that they are fine for the ‘little guys’ but don’t play in the ‘big boys’.

Let me also state that while many of our larger customers initially chose an on-premise deployment, many have either converted or are in discussion with us about converting to on-demand.  More significantly, the majority of new customers are choosing to go on-demand.  This trend is also being observed by SAP as announced at their SAP Influencer Summit yesterday.  While I have to agree that Business ByDesign is aimed at small to medium enterprises (so the ‘little guys’, not the big boys’) SAP stated that on-demand inquiries have gone from 1 in 10 last year to 1 in 2 this year.

Let me also concede that for many ERP functions the only incentive for putting things in the ‘cloud’ is one of cost effectiveness because many of the core ERP functions do not stretch outside the organizational boundaries.  And yet two of the functional areas that are seeing huge increases in adoption of on-demand solutions are customer relation management (CRM), or sales force automation (SFA), and human capital management (HCM) or human resources management (HRM).  I don’t know what could be more confidential than a company’s sales order pipeline or their employee records, including employee evaluations.  OK, maybe I will concede that the core financials are more confidential.

But I do find it interesting that Herbert considers the core ERP capabilities to be most applicable inside the four walls of a company. What surprises me is that she considers supply chain management to be restricted to inside the four walls of a company.  Our observation is that that for most of our customers outsourcing has meant that increasingly little of the supply chain is owned by the companies, especially the brand owners.  If these companies had the myopic view of the supply chain being only that part of the process in which they own the materials or product they wouldn’t need any of the SAP supply chain management suite because they outsource most of their manufacturing, in many cases never touching the product.

It is our observation that leading brand owners in high-tech electronics, consumer electronics, aerospace and defense, and life sciences need greater visibility and control of the end-to-end supply chain in order to provide reliable promise dates and to be able to deliver according to the promises made.  As inventories have been squeezed out of the retail and supply chains locations, the need for greater responsiveness and agility has increased enormously.  Ask any electronics manufacturer about the availability of key components over the past 12-18 months and you will hear stories about commodity items that could be purchased with a 2 week lead time as little as 2 years ago that now has 13 week lead times if you can find a supplier.  Given the buy-sell relationship many electronics OEM’s have with component suppliers (in which they buy items from the component suppliers and sell these items to the contract manufacturers) it is clear that they need a lot more visibility into and control over the supply chain than is provided in ERP systems, which is the core reason for their increased interest in on-demand SCM solutions.

What about your company?  What sort of ‘cloud’ strategy are they adopting?  What sort of applications will they be most interested in deploying on-demand?

The way projects are run have changed significantly since I started consulting 19 years ago.  In those days, it was unheard of not to be onsite at the client Monday through Friday working on a project.  Even though during that time you may only spend a few hours directly with the client.  Of course with the advances in technology (laptops issued to everyone, VPN, mobile/smart phones, VOIP, etc.) the consulting world has evolved.  While we once had to be onsite 100%, that then changed to 75-80% (7-10 years ago).  Clients sometimes let the consultants work from home one day a week.  The clients still had the mindset that they wanted to see the people who were doing work for them to ensure that the work was being done and they got what they paid for.

Fast forward a few more years to implementing Software as a Service (Saas).  The world changed again.  Most Saas vendors have an implementation approach that has much less onsite activities than a traditional software implementation.  Consultants typically will be onsite for specific activities or milestones while the remainder of the work will be performed remotely.  With access to servers in the cloud, web conferencing products, and more standard implementations due to less customizations, the need to be onsite is less critical. 

I certainly do believe there is less need for onsite work for a Saas project; however, there are critical activities which I do believe should be performed onsite:

1. Project Kick-off – the entire team should be onsite to set and hear expectations for the project.  Also to build rapport amongst the team and document how the team will work together during the project.
2. Requirements and Design – all requirement review and design sessions should be performed onsite so the teams can ensure both sides have an accurate understanding of the requirement and how it will be satisfied.
3. Testing – during end-to-end and acceptance testing the teams should be together to provide knowledge transfer of the solution, answer questions and troubleshoot and resolve issues quickly.
4. Production – during production cut over it is important for the teams to be together to resolve any production issues quickly and answer questions.

These may not be the only times when the teams should be together, but I believe these are the most critical.  If the client is struggling with understanding the solution and taking ownership of the solution, then more onsite work may be required.  Consultants need to watch for this and be flexible to change the schedule to best meet customer needs.

In order to make this model work, it is critical to set the appropriate expectations in the sales cycle.  Most clients will agree with the approach once they understand how it will work.  Clients are also increasingly budget challenged and the cost savings of not having all consultants onsite every week will be attractive.  Although, cost concerns should not outweigh whatever is required to make the project successful.

What are your thoughts and experience with performing remote work?

This has driven the growth in ERP and other planning systems in the last decade, with the goal of a fully integrated system from top to bottom, allowing maximum responsiveness with minimum slack. Many companies have come to realize, however, that most enterprise systems are either not actually integrated, have weak links, or lack some required functionality. This has led to numerous systems being implemented across the enterprise, with varying levels of integration between each one, ranging from none to very tight integration.

The implementation of these various systems has been driven by the needs of the various business units, which often have very different requirements and priorities. This in turn has led to a disconnect in common data terminology and usage across the enterprise, as each area of the business focuses on the data required to meet their immediate needs in their own terms. When the time comes that an enterprise solution is to be implemented across several different business units or functional areas, it is then discovered that the definition of the same piece of data differs from unit to unit or area to area. This leads to the necessity of building exception handling rules and look-up tables in order have the data flow through the enterprise with consistent meaning. This can greatly add to the project’s cost and time to implement, and is usually an unexpected complication of the project. It also significantly increases the amount of effort required to support the solution.

The question becomes, what is the best way to deal with this situation in order to reduce cost and timeline impacts? Following are some suggestions that might help mitigate these issues:

1. Perform an audit as part of the preliminary planning phase. While this will not do much to fix existing data issues, it will highlight gaps in the ‘data chain’ across the enterprise that will need to be bridged. Key data fields should be identified and their exact meaning to each functional group in the organization should be spelled out. This will quickly identify areas where cross reference tables or extra business logic is required.
2. Centralize the administration of business rules and data schema, especially as they apply to enterprise-wide initiatives. While ERP systems generally ‘hang together’ because of their module interdependence, the business apps that reside above this transactional layer tend to be more isolated. When an enterprise-wide application is implemented to replace and integrate these business functions, the gaps become readily apparent. The most successful method I have seen used is to drive all data definitions from the transactional ERP layer, or the layer where the best cross functional integration occurs, and build a common base on top of this.
3. Plan and implement every business process as an enterprise-wide initiative. This will ensure that data and business rules are defined at the enterprise level, not at individual, possibly differing functional units. However, in order to do this, it is much easier if you are using a tool that supports enterprise level business processes. This includes the ability to tie disparate data sources together, large multi-user scalability, and is flexible enough to be configured to meet the varying requirements of all the functional units involved.

While I have not covered all the different techniques that can be applied to help mitigate this very prevalent issue, I hope I have given people an idea of where to start in tackling this significant implementation problem. If anyone has other ideas or techniques they have seen or used, I am sure everyone in the community would be very interested in hearing them.

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 haven’t yet had time to catch up on the latest Twitter comments, but I had to laugh out loud at a tweet by Dennis Howlett musing over the Oracle MarCom team’s efforts to reign in the barbs that Larry Ellison will throw at SAP and HP.  There is some really good comment (and speculation) by Dennis Howlett, Tom Wailgum, and Josh Greenbaum on what the appointment by HP of both Apotheker and Lane could mean.  I agree with Dennis Howlett that Leo Apotheker taking the CEO job at HP is worth a comment on its own, but the combined appointment of Ray Lane by HP makes this newsworthy.  But I am confused because both Apotheker and Lane are software guys who have been appointed by a hardware company (HP), while a hardware guy, Mark Hurd, has gone to Oracle, which is a software company despite its recent purchase of Sun.  Or maybe that should be Oracle was a software company until its recent purchase of Sun and Larry Ellison’s keynotes at Oracle World?  Now if Larry Ellison had hired Leo Apotheker instead of Mark Hurd, that would have been interesting.

There is also an interesting comment by Ray Lane on what this could mean strategically.  Ray muses that HP needs to up their game in terms of a combined software, hardware, and services play, extending beyond Oracle’s ‘appliance’ play of software and hardware.   In this vein there is also much to comment about HP buying SAP, while Dennis Howlett flips this around to speculate about SAP buying HP.  Who knows.  All I know is that there has been little that has caused as much stir in the blogosphere and twitter universe concerning the enterprise application market.  I am much more comfortable commenting on the space than reporting on the space, but this is too big.  I have to report this.

There is something going on and only time will tell how it will play out.  Will we see what appears to be Ellison’s strategy of combining hardware and software prove to be successful?  What does this mean for the likes of Microsoft and SAP?  Anyone heard the rumor that Microsoft is getting out of the enterprise application space, that is Dynamics?  Microsoft’s moment was when it separated the operating system from the hardware, thereby commoditizing the hardware and dominating the desktop, but from an operating system perspective.  Yes, Microsoft has gone on to dominate the desktop application space with Office and Internet Explorer, but it started with the operating system. Are we really seeing the moment when the operating system becomes commoditized by the combination of hardware and business applications?  Only time will tell.