SAP HANA – it’s like an episode of Gold Rush


Last week, SAP made their big announcement that their business applications – SAP Business Suite – now support running on HANA (High-performance ANalytical Appliance.. I guess naming it “haa!” wouldn’t have been appropriate).  From my perspective, the goal is twofold:

  1. Entice clients to upgrade to new versions of ERP.  Offering the ability to inject more intelligence into business processes embedded in SAP by enabling BI-like analytics to happen in-line and in-context using an in-memory database architecture (I know, lots of “in’s”).  This might allow things like improved fraud detection, more flexible and targeted pricing, and generally more agile business processes.
  2. Consolidate the stack.  Today, most SAP ERP shops are running IBM (where I work), Oracle, or Microsoft databases underneath their SAP apps.  With HANA, and the recently announced free Sybase add-on, customers can consolidate on one vendor instead of having to manage two.

From a customer perspective, the benefits are potentially new, more agile business processes, and (maybe) lower costs.  But in order to get this benefit, I have to replace the underlying infrastructure on a massive, complex set of applications that I have heavily customized over the past 15 years.  Granted, I don’t have to do this all at once, but if I have a large deployment, it’ll cost me between 10-50% of the initial implementation cost, assuming HANA is like a normal technical upgrade – and HANA is a pretty major shift – so this won’t be cheap.  And what business processes are we talking about?  Is there payback in making them more agile?  Not every process needs a ton of intelligence.  Taking a step back from all the hype (which is considerable), I have to ask the question – isn’t there a simpler, more effective, and less costly way to do make processes more intelligent and agile?

In-memory technology has been available in a lot of BPM solutions for some time – it’s called operational decision management, BRMS, CEP, etc.  And this is just one of a couple ways you can inject intelligence into a business process managed by a BPMS.  I know the technology guts of HANA are fundamentally different from BPM, but if the goal is to make business processes smarter, BPM presents a less costly, and less risky way to achieve this than many of the use cases for HANA that I’ve seen.

It kind of reminds me of an episode of Gold Rush I saw a while back.  A mining team did some tests on a new tract of land they wanted to mine.  They found gold!  But in order to get to the gold, they had to remove 50 feet of mud.  The cost to remove the dirt exceeded the value of the gold that was down there.

And like the gold miners who chose to look for another place to mine, I’d be willing to bet that there are more fertile grounds for businesses to be investing than replacing the database under their ERP system.


When process becomes more important than content, you’re dead


In this month’s Forbes, George Scangos, the CEO of Biogen, a pharma, had what I thought was a great quote:

“When process becomes more important than content, the company is dead”

In this case,  Scangos was referring to the bureaucratic approval and review process that he encountered when he first became CEO at Biogen.  Internal teams were focusing so much on the review process, that they lost sight of what they were supposed to be doing – bringing new drugs to market.

I see this kind of thing happen with BPM – usually at a client that is just getting started using the technology.  You get so focused on the mechanics of BPM – process discovery, process modeling, playback, deploy, optimize – that it can be really easy to miss the main drivers for adopting BPM in the first place!  If you are automating a broken process, or optimizing an outdated way of doing things, your BPM project is dead.  BPM is about working together more effectively, and improving how you work over time.  The technology is just an enabler to accomplish those goals.

How HP may lose $5 billion today…and what it might mean for BPM acquisition targets


An article on slate today walks you through how HP may have to take a $5 billion haircut on the value of Autonomy.  Meg Whitman, CEO of HP, is now saying that operating margins for Autonomy are around 30% – not the 40-45% origninally thought.  Remember, HP paid a little over $11 billion for Autonomy.  And now they have to write down almost half of that? Ouch.

How did they get it so wrong?  The Guardian gives you a couple of potential scenarios, like channel stuffing, mixing hardware and software sales together, and other ways to cook the books.

But one area that may cause problems for our industry as a whole is how you recognize pay-as-you-go revenue for cloud services.  Autonomy runs what they claim is the largest private cloud in the world – measured by amount of data stored at 50 petabytes.  This is offered as a pay-as-you-go service.  There is a lot of variation in how expenses for running data centers are booked – many times it is isn’t easily found in a company’s SEC filings – which can have a big impact on margins.

Specific to BPM and middleware, there have not been any issues with accounting like what we’re seeing at HP.  But as clients purchase software in increasingly complex ways, BPM portfolios grow, and people start blending on premise with cloud execution models, the need for good accountants is going to increase dramatically.  I think the biggest areas where this will be challenging will be for BPM vendors that are acquisition targets.  How will potential acquirers ensure that they have an accurate valuation of future revenue streams for cloud-based BPM vendors?  If the data center expenses are coming from a third party, such as Amazon, how are those reported?

In the meantime, it will be interesting to see how the drama at HP unfolds.

Is BPM the new Taylorism?


I read an interesting series of posts from Scott Francis of BP-3 and Max Puscher of ISIS discussing the business value behind BPM.  Max’s post is from 2010, but it raised an interesting thought that I think is worth looking at.  I won’t post the whole thing here, but the gist of the article is this:

We are…going backwards with BPM to Tayloristic management concepts.

What is wrong with the idea of BPM as implemented in many BPMS, is that huge amounts of time have to be spent to analyze process flowcharts that the people then have to adhere to…Only a small percentage of work (20%) might be that stable…

The most popular fad is now to buy drop-in process packages for BPMS to speed up implementation… Businesses often buy ERP because they are buying the hardcoded processes to improve the way their businesses work, lacking the skill to do it themselves. That is all the hardcoded processes a business can survive. Encoding more processes in BPM is not beneficial.

…the greatest of people WILL BE held back by the bureaucracy of methodology and by those hardcoded processes made for low-cost, unskilled, and simply replaceable staff.

The solution in Max’s post is:

Technology must allow processes to evolve to any structure they might need at any point in time without bureaucratic overhead. The focus must be not to cut cost, but to make the best people (knowledge workers) the most productive and effective. The most important knowledge workers of a business are at the top management level.

I think there are two things to think about here.  First, does modeling a process restrict innovation?  And second, should the focus of IT be on enabling top management to be more productive and effective?

Let’s talk about process modeling first.  To start with, the solution you pick to model your process in makes a big difference.  Having done my share of ERP implementations, I can tell you that if you’re trying to solve the same kind of problems with BPM that ERP addresses, you’re probably not doing it right.  Done right, BPM and ERP solve two completely different challenges.  ERP should focus on those processes that are non-differentiating, or things that for regulatory reasons have to be the same as your competitors.  Examples include basic accounting and payroll functions.  It’s not so much that customers of ERP lack the skill to implement these in BPM – it’s an economic decision to leverage something off the shelf.  When ERP fails, it’s usually because it has been overly customized and expanded beyond these basic, non-differentiated business processes.  You can also crash and burn when you try to turn BPM into an ERP or CRM system with massive prepackaged processes that take months to implement and millions to deploy.  And in the process, you’re killing any chance of differentiation in that process.  Large, complex, prepackaged BPM applications are like a 1976 Thunderbird – fast to get started, but don’t try to make a turn or it’s game over.

And does modeling a process inhibit innovation?  I couldn’t disagree more.  Done correctly, modeling a process is about quickly understanding something that was previously not collectively understood.  This collective understanding doesn’t inhibit new ideas – it does the opposite.  You may decide that it does not make sense to implement the process in a BPMS, but often you will discover ways to innovate by having the dialog.  The trick is to engage all stakeholders (not just a few process experts) in a timely and cost-effective way.  If it takes two months to model a process, you’re doing it wrong.  BPM isn’t the answer to EVERY problem out there.  But if it is a differentiating process, I’ve seen first-hand how it can have a positive impact for people.

Moving on to the second point, about how IT should focus on enabling top management.  Again, I have to disagree.  IT’s unbalanced focus on top management has been the problem!  When you have employees purchasing their own iPads, using services like Yammer, gmail, etc and basically circumventing IT, what do you think that is saying?  It probably isn’t a revolt against BPM.  Furthermore, the economics of most packaged applications make it impossible for more than a few knowledge workers to have access to the systems that a typical company spends the majority of their IT budget to maintain.  Even large-scale deployments of packaged apps usually only reach 20% of all employees.  What about everybody else that participates in a business process? You’re on your own, or you use a point app that is disconnected from the overarching process.  This is exactly the space that BPM can address.  Because IT involvement is not mandatory for every change to a process, the incremental cost of BPM drops as you scale it out to more users.  Making better information available to the people closest to the process is the key to agility.  What good is knowing a shipment will be late if only the CEO knows about it?  Isn’t that information more valuable to the warehouse manager?

Done wrong, BPM can be exactly what Max Puscher describes – a Tayloristic soul-sucking waste of everyone’s time.  But you could say that about a lot of software products!  After all, most software is about helping you to do your job better.  If you botch it up, it will make your job harder, not easier.  But done right – with broad participation, focusing on differentiating processes, and putting more power into the hands of people closest to the process – BPM can be a powerful tool for innovation.


Fail your way to success


It’s my favorite time of year.  Analysts hang their questions on surveymonkey with care, while visions of harvey balls dance in their heads.  Or something like that.

In one of the first “trendy” reports of the holiday season, IBM released the 2012 Tech Trends report.  You can get your copy here.

The report covers the usual stuff about the shift to cloud, mobile devices everywhere, etc.

But the most striking finding of this study for me was the difference between leaders (or “pacesetters”) and laggards (called the more politically correct “dabblers”) in the area of experimentation.  Check this out:

Pacesetters are nine times more likely to experiment with
technologies that don’t yet have a clear business application,
and twice as likely to proactively develop skills to meet
anticipated needs.

What isn’t discussed in the report is how this kind of experimentation actually gets implemented.  When you do a lot of experimentation, you’re going to fail.  Usually a lot. Articles from the WSJ,  Stanford School of Business, and numerous other studies confirm that the path to success is usually strewn with failures.

One of the most powerful things that technologies like business process management can do is to lower the cost of failure for experimentation.  By reducing the cycle time from ideas to inception, you can try out a LOT more ideas than if you were implementing a massive piece of code.  And this “safe environment” doesn’t have to be something hidden away in a lab somewhere in your organization.  It should be a place where everybody can experiment – technical and non-technical people.

Hopefully 2013 will be a year of trying new ideas, and embracing those “learning moments” “opportunities for growth” “planned enhancements” “challenges” “unplanned outcomes” failures.

IBM, Oracle, Red Hat, Active Endpoints, and Bonita at the BPM-CON Thunderdome


Today, an online conference called BPM-CON featured a number of BPM solutions, including IBM BPM.  I thought the conference was good if you need a quick update on the latest and greatest from these solutions.  I always find it interesting when you can see presentations from different vendors back to back.  It’s kind of like a wine tasting.  Some things are obvious differences, others are a little more subtle.  And your brain will feel a little fuzzy afterwards.

Here’s a quick rundown of what was presented, and a few things to look for.

IBM – Dave Keyes did a nice job giving an overview of the IBM solution for BPM and Decision Management.  A few customer examples illustrated how the technology can be applied.  And a view into the future of our BPM solutions, centering on cloud and patterns.  You can get more information on patterns and what’s available today here

Bonita & Talend did a joint presentation.  Talend OEM’s Bonita with their MDM offering and have been partnering around ESB too.  Talend presented some interesting data on a customer survey they conducted of over 200 integration pros.  Not surprisingly, they found that customers are most challenged with processes that span multiple applications.  But surprisingly (at least to me) was that more than half of respondents said that Help Desk processes were a top concern for BPM.  I guess it depends on how you define Help Desk.  There was a strong focus on SOA from the Talend presenter, and the Bonita presenter focused more on the traditional BPM topics of process design and execution.  I would have liked to see more details on how the two products work together beyond the high level charts, especially since it was a joint presentation.

The presenter from Oracle started out by defining what Oracle is calling “intelligent applications”.  Basically, Oracle is positioning BPM as a new way to build apps that require a lot of change.  And you can see why with the templates that Oracle is building to work with specific Fusion Apps, called “process accelerators.”  I liked how he then tied this idea of intelligent applications to some specific use cases with the underlying technology, such as fraud detection.  What was missing was any customer stories.  Based on this presentation, it looks like Oracle has good vision, but it is difficult to see how that vision will become reality.

Red Hat spent a lot of time on their roadmap and how the open source model works.  Not surprising as the roadmap has some major changes with the acquisitions of Polymita and FUSE, along with the new 5.3 release and all the changes made on the BPM end of things with that release.  Red Hat’s vision is the “intelligent integrated enterprise.”  For me, this message is focused on event detection (via CEP) and decisions you make around those events – with BPM as the “what you do after the event is detected”.  I think TIBCO and Red Hat have a very similar vision here.  The big challenge for Red Hat is how they manage the roadmap and transition and integrate the BPM parts from Polymita.

Active Endpoints had their own spin on intelligent BPM.  The presenter focused on mobile.  And he gets props for giving a live demo.  The demo showed a instance getting integrated with his iPhone via ActiveVOS.  He also used Siri for things like adding notes to the CRM record through his iPhone, which was a nice touch.  This is all part of their Cloud Extend product, that is built on  Much more developer oriented presentation than the others, and really focused on  I would have liked to see how this could be applied beyond mobile and  But overall, I found this presentation to be very informative.

Registration is required, but the materials are available and you can hear the webcasts on demand for each vendor here:

Information Week survey: Got Innovation?

Interesting survey out this week put together by the folks at Information Week looking at IT innovation and a the relationship between IT and line of business.  You can get your copy here (registration required).

The report is well worth a read.

One of the stats that really got my attention was this one:

 We’d be dead in the water without IT: 60% of IT pros agree, only 43% of biz pros see it that way.

Let me read that to you again.  Only 60% of IT pros feel that they would be dead in the water without IT.  If you work in IT, and they get rid of it, you are pretty much dead in the water.  Not just mostly dead.  Completely dead.  And in the water.

When asked how important IT is to innovation, 32% of IT pros say extremely important. Only 25% of business pros agree.

This statistic really got me thinking.  If only 1 in 4 people who are supported by IT feel like IT is helping the company innovate, then what do people think the purpose of IT is?  According to the study, most view IT as a maintenance organization.  With the vast majority of IT budgets going to maintaining the status quo of enterprise apps, it is not totally surprising to see this number from the line of business.  But when 68% of IT staffers believe that they are not a source of innovation – now we’ve got a real problem.

Eric Kimberling of Panorama does a nice job on articulating some of the challenges with ERP deployments – a bucket where big chunks of IT spend have been going for the past few years.  Panorama does an annual survey of ERP users and what they find every year is pretty eye-opening.  Roughly half of ERP projects fail to deliver even half of their expected benefits.

Why?  I would argue a big reason is that it takes too long to roll out, and what you are putting into production is often not unique.  The result is what we see in the Information Week report – a lot of people in both IT and LOB end up saying that innovation is not something that IT delivers.  I’m picking on ERP here, but this  challenge is not limited to that domain – long projects that don’t deliver anything unique can happen in a lot of domains.

So how do you fix this innovation gap?  How do you get the mojo back for IT?  I think it starts with focusing more on adoption of technology, a renewed emphasis on doing unique things rather than “best practices”, and moving away from excessively long rollouts of new software.  I know this is easier said than done, but when you think about it, innovation requires three things in order for it to take hold.

  1. First, you have to be doing “new” things and not just maintaining stuff.
  2. The new things you are doing should be unique.  Nobody innovates the cow path.
  3. And third, you have to be trying a lot of new things.  The more people you can engage in the process, the better.

The only way to accomplish all 3 of these things in a way that makes economic sense is to do more projects with smaller scope, engage the broadest possible audience, and focus on the things that can differentiate your business.  All of these things are in the sweet spot for BPM solutions.  Putting in place a BPM solution doesn’t magically make innovation appear, but it creates an environment where innovation has a chance to take hold and grow in IT.