About Us Our Team Our Investments News Investor Info Blog

Archive for the ‘Innovation’ Category

Process vs Innovation?

Thursday, March 19th, 2009

I was reading an interesting discussion on a BPM forum about whether innovation is a odds with process. If you understand process to be a rigidly structured, unchanged prescription of how work gets done, then there certainly is truth to that. The main task of those types of processes is to make sure work is standardized, and done the same way. Innovation is frowned upon.

On the other hand if you think of process as including ad-hoc and unstructured business processes - then processes actually help with innovation. If you can gain understanding of how things actually get done  (as opposed to how they are supposed to happen) - then you can use that insight to generate innovation.

Take any structured process (e.g. CRM), and look at the work it generates outside of the system (for example via email). Sometimes the work is really an odd ball one off. But in other cases (especially if it repeats itself) it may be an indication of a new unfufilled need, or a change in the environment that should be handled. Exactly the kind of input you need to create useful innovation.

I think companies are loosing a lot of potential innovation by not capturing and analyzing the exceptions to their main stream processes - I think they would be surprised by what they learn.

eMail and Human Process Management

Monday, July 14th, 2008

Zvi referred me to an interesting post on read-write web on Is Email In Danger? by Alex Iskold, and in many ways the comments were just as interesting as the article. It is clear that email vs. twitter vs. IM vs. wiki is a topic that interests people.  Even though those tools overlap in functionality, I’d bet each will find its proper place and there won’t be one winner.  It would be interesting to see the best practices that are forming about when people use which tool. Just like Fedex, US Mail and email all coexist comfortably…

Personally I am sure that at least in a corporate setting, email is not going to be replaced in the foreseable future. The main reason is that email has become more than just “electronic mail” it has become the implicit mechanism of choice for managing many (if not most) the Human Processes in most organizations.

Using email for unstructured human centric processes is both its strength and its weakness. Just the fact that email is amenable to so many diverse, unstructured processes (and all without IT support) is a huge benefit, the downside is that email isn’t really optimized for managing those processes (but rather for single messages) - so we get Information Overload in our inbox. Threaded conversations are an interesting innovation, but they don’t solve the problem either.

Think about it - in many companies there are specialty systems for the “standard, heavy-duty” processes (like ERP, CRM), but for the other processes (or as someone coined the outside SAP - or OSAP processes) - what does everybody use? eMail! Even if you have a system in place for a specific process - how do you handle exceptions? eMail! How do you work across organizational silos (or across companies)? eMail!

So as I said, I don’t think eMail will be going away any time soon.

Incubating Innovation – part 2

Sunday, December 30th, 2007

I am at heart a technologist. I still get excited hearing about new, cool software technology and solutions. All of my past experience, and now at eXeed, my time goes into figuring how to mold new technology so that it solves a real problem for a large set of potential customers. At IBM Research our group used to use the term “Research in the Marketplace”. Continuing that tradition at eXeed, we work pretty much only with startups that have unique technology, so my comments are very much focused on technology based startups.

In my previous post I tried to show why the numbers make it hard for corporations to create “startups” internally. Beyond the numbers, there are two basic truths about technology based startups that make it very difficult to cultivate them in a large corporate environment:
1. Over a short period of time technology-based startup products need to morph (sometimes repeatedly) to meet customer\market needs –experimenting in the marketplace  while leveraging the same basic core technology. Very few technology startups start with the same set of product (ideas) and business model as they exit with – but in most cases the new direction still leverages the same core technology. 

2. Startups start out small, with very little (if any) revenue. One thing to remember is that even an exponential curve starts out slow – and only speeds up as time goes on.

These two “facts” make it hard for a startup to be incubated in a large company – there are just too many barriers to being nimble enough to make point 1 work, and point 2 usually means that the corporation looses interest before success can be shown (especially given the ambiguity associated with point 1, and since there is usually an existing set of products that can generate more short term revenue with the same investment).

I guess the basic point is that the impedance between running an existing business and starting a new one is so great that unless the corporation is willing to experiment with new, unorthodox models, and can commit long-term high-level executive support, it just won’t work. Even then there is still the issue of getting the right people (and giving them a loose enough rein)  – but I will discuss that in another post.

Software as a Service and Hardware Virtualization

Thursday, November 15th, 2007

I have been musing lately about the connection between software delivered as a service and hardware virtualization. For me they are two sides of the same coin (I guess we could have just as easily called it Hardware-as-a-Service and Software Virtualization). The simplest way to implement a SaaS’ified version of an existing application is via Virtualization – just run as many instances of the application (or application components) as needed, each in their own virtual machine.

The down side is that this may not be very cost effective. First, you need to be able easily deploy and manage new instances of the application within you virtual environment (and hence VMWare’s acquisitions of Akimbi and Dunes), have a appropriate pricing model for the various components technologies that make up the application, and the ability to easily monitor the virtual vs. real machine resources needed for the application.

It is not always easy to reconcile the software component models with virtualization. Many traditional software vendors charge per instance of their application deployed on a server. So if you want to deploy a DBMS for each instance of the application – the price can be quite prohibitive. It would probably depend heavily on the number of users per instance, but for many SaaS applications there are only a few users per instance. You could rewrite the application so that you could use a shared DBMS, having each application instance use a different DB in the DBMS – but rewriting an application is very costly.

Monitoring all those instances isn’t easy either. You somehow need to correlate all the virtual instances with the physical resources on the machine. One of the key reasons to virtualize is to be able to use machine resources (especially the CPU) more effectively – which means you want to load as many instances as possible before having to buy a new machine – very different then what is available from today’s monitoring tools.  A good overviewof these issues by Bernd Harzog can be found here.

So what’s my point? I think that we’ll see SaaS take-off when it really easy to take an existing app, and created a SaaS’ified version of it – and that will happen when it is as easy as taking a “virtual version” of the application and deploying it for “tenant” as needed. We are still missing some pieces of the puzzle for that to happen, but my guess is that we will see it happen in the next couple of years.

Subprime Mortgage Crisis and Startups

Monday, October 22nd, 2007

I am not sure why we haven’t heard more about the effect of the sub-prime mortgage crisis on startups and VCs, but it seems clear to me that we will see an effect. The bad 3Q results (and bad 4Q forecasts) for many financial institutions will have a delayed effect on many later stage enterprise software startups. 

The Finance industry is a very large consumer of technology, and in many cases willing to be an early adopter of interesting technology. Of course, as with any downturn, new initiatives are always an easy target, and usually the first to go. Many enterprise software startups pin their hopes on selling their products to large US financial institutions. Those that have already signed deals- congratulations! Those that have deal propects in the pipeline, but haven’t signed the deal - don’t count your chickens, at least until the banks start growing again. 

No matter how the larger economic issues play out - the subprime  mortgage crisis will be a bad deal for startups.

The Long Road towards Integration – Part 4

Sunday, October 21st, 2007

I am sort of surprised that I am back on this subject again, but when I read that Microsoft’s Ballmer plans to buy 20 smaller companies next year (Ballmer: We Can Compete with Google) it drives home for me the importance of being able to integrate well in the aftermath of M&A. My best guess is that those 20 companies will include 1-2 large companies, the rest being small and midsize companies - companies that are “innovating in the marketplace” (a term we used to use at IBM Research). So Microsoft is effectively outsourcing a good portion of their innovation, and placing a big bet on being able to integrate these acquisitions into the fabric of Microsoft.Thee types of smaller acquisitions seem to be in the cards for IBM and Google - and I think more and more technology companies will be outsourcing their innovation this way - augmenting internal “organic” growth with external  ”inorganic” growth. Oracle seems to have gotten this down to an art (though they tend to swallow whales rather than minnows), and even SAP has jumped on the bandwagon. One issue that will clearly come with these acquisitions is how the acquiring company doesn’t kill the spark of innovation that exists in these smaller companies  (of course that is assuming that they want to keep the innovation alive, and aren’t just buying a specific technology or existing product.I had the opportunity the other day to speak with someone that was on the Corporate side of an acquisition and discussed what was their thought process at the time of the acquisition, and how that differed from how things turned out after the acquisition.One thing that struck me was that both sides were fooled since they were (paraphrasing Bernard Shaw)  ”two companies separated by the same language”. The company being acquired thought they were communicating important information about the acquisition, but it turns out that they were using internal shorthand to describe people and situations, which were interpreted completely differently by the other side. This was probably exacerbated by the fact that one side was Israeli and the other American - but it could have happened with any two companies - especially when there is a high impedance mismatch between the two (or in English - the companies are of very different size). . For example when one company said a manager “kept the trains running on time” - they meant a clerk that could keep to a schedule - while the other side thought  they meant someone could manage a complex system with all its nuances and make sure that it keeps working. Understandably these kinds of miscommunications caused a lot of faulty decisions to made during, and right after the acquisition.In my experience it takes about 9  to 18 months until the sides really start to understand each, how the other side works - and how they need to work together. That is assuming that everything goes smoothly. If you try to speed it up too much - you will end up killing the innovation, and you may end up killing any possibility of a successful acquisition.So what is the bottom line? Assume that you will need to keep the current structure of the acquisition intact for about a year before you can make any drastic structural or strategic changes. See the rest of my recommendations in previous posts - and perhaps hire a consultant that has been there and can help smooth the transition.