About Us Our Team Our Investments News Investor Info Blog

More on Naming HPM

September 23rd, 2008 by Jacob Ukelson

I read some some articles on “Dynamic BPM”, one by Scott Byrnes of HandySoft (http://www.dmreview.com/dmdirect/20070323/1079086-1.html) and a newer take on the same theme by Ian Louw from PNMSoft (http://bpmfundamentals.wordpress.com/2008/09/16/information-overload-making-a-case-for-dynamic-bpm/) and thought that perhaps Dynamic BPM could be a possible candidate for a name instead of HPM. So I did a quick search of Dynamic BPM and came back with a blog post by Sandy Kemsley (http://www.column2.com/2008/09/gartner-bpm-dynamic-bpm/) which points to Gartner’s use of Dynamic BPM as a way to descibe the addition of external rules to a BPMS - a very different take on things than the other usage (which focused on email overload).  That brought home something that I suspected - any name that uses a prefix to “BPM” will be considered just an additional feature to BPM - and I believe that HPM is a fundamentally different (though complementary) category.  It isn’t that I don’t think external rules will be a valuable addition to BPM toolkits, it is just that they won’t solve the problem of ad-hoc, evolving, human intensive business processes now being managed through meetings, documents and emails. I think managing those types of processes will require something very different than what is available in today’s mainstream BPMS.

Dynamic Business Applications and HPM

September 20th, 2008 by Jacob Ukelson

I was reading a Forrester report “The Emerging Technology Trends that CIOs Should Care About“  and was struck by what they call “Dynamic Business Applications”  where they claim that “Most business applications are too inflexible to keep pace with the businesses they support, as they force people to figure out how to map isolated pools of information and functions to their tasks and processes, and they force IT pros to spend too much budget to keep up with evolving markets, policies, regulations, and business models.” I couldn’t agree more, especially since they break this out separately from BPM.

This is especially relevant for the fluid environment needed for the kind of work done by knowledge workers, especially for ad-hoc processes or exception handling. This type of work needs a new paradigm where the ad-hoc, human way people actually handle most process needs to be the guiding mechanism. Knowledge workers use an implicit process framework that they use for their tasks, but almost every instance is some sort of exception. I think this one reason the use of email is so pervasively used by knowledge workers for their processes. This very different from the structured processes that are handled by BPM - and we’ll need a new paradigm for it. I have started to use the term Human Process Management - but I am not sure that is the best name for those ”process frameworks (usually handled via email and meetings) for ad-hoc “unstructured” human centric processes.

Bottom Up vs. Top Down Process Understanding, or Another Difference between BPM and HPM

September 16th, 2008 by Jacob Ukelson

I was at the Gartner BPM conference last week. Walking around the vendor showcase, one thing that struck me was how similar all of the vendors offerings seemed to me (with a few exceptions). Sure some were traditional enterprise software, some were SaaS, some vendors stressed one set of features, while another stressed a different set - but to me all the vendors in certain BPM space (document centric vs. integration centric) all looked pretty similar. I am guessing most people interested in a BPMS feel the same way.

What interested me was how they proscribed the process for creating a BPMS based application to implement an existing  business process. For most, the first step is to create a model describing the process - using a BPMN modeling tool. The model is usually created by a business analyst (usually someone in the IT department) that understands the process.  This model is a high level description of the business process which is used to bridge the gap between the business (they understand the process) and IT (they understand implementation and data). What struck me was how much the methodology reminded me a of the “traditional” top down ways of creating software .  Since it very difficult to automatically create the actual complete, executable production system from the BPMN model - the model serves as a requirement definition for the development phase - which is handled by IT. Any end-user iteration and understanding is around the BPMN - which is a very abstract description of the process to be implemented.  This is then handed to the IT folks for implementation - with the standard lag of months between requirements and actual system. This will work fine for processes that are rigorously defined, unchanging and complete, it may work for processes that are rigorously defined with a small number of exceptions - and will completely breakdown for ad-hoc, unstructured Human Processes. The reason is that these ad-hoc human processes are not well defined, and exceptions are the rule. The only way to approach this is same way you approach building human intensive software  - iteratively, working intensely with customers on working prototypes - either low-fidelity or high-fidelity. John Gould and Stephen Boies taught me long ago that iterating on the spec (i.e. requirements or model) just doesn’t work.  I also learned that if you are implementing an existing process - you want to keep it as familiar as possible to the users, which means let users continue to use whatever they are used to (or feels natural to them) whenever possible.

This is why I think that existing BPMS vendors won’t do well in the ad-hoc, unstructured Human Process space. It will require a much lighter weight, flexible (or bottoms up) environment where processes can be easily created, modified and tested in the field - with the turnaround between versions (including the initial version) is measured in days (or hours) instead of weeks or months. I personally believe that the more Human Process Management Systems let users remain within familiar user environments (currently eMail and MS Office tools, Wikis and other tools in the future), the easier it will be to get these systems accepted by the organization and end users.

More on Human Process Management

August 27th, 2008 by Jacob Ukelson

I have been thinking some more about Human Process Management, especially how it differs from Business Process Management. Certainly one key difference is whether the process is structured or not - i.e. whether you can prescribe the execution of the process based on some model of the business.

It is clear that there are a number of mainstream business processes that lend themselves to such a model (e.g. ERP,CRM), but I claim that most processes in an organization are human2human (or people2people) processes and the tend to be ad-hoc and dynamic. It turns out that even structured processes have a large number of exceptions - that tend to be handled in relatively ad-hoc, case-by-case manner.

I was reading an old blog post by Pravin Indurkar where he looked at B2B EDI purchase order transactions at a small business and found that though there was one standard process -there were 65(!) different variations depending on the nature of the order. While it would be possible to model all the possible process paths - it certainly would be time consuming and expensive. My guess is as soon as you model the 65 different possibility there will be a 66th and 67th that are used to take into account variation and business conditions - so the way these are handled is usually through an unmanaged human exception process. These human processes are either exclusively human to human process (collaboration) or human processes that invoke various systems as part of the process (or what Barry Briggs calls human-down processes).

These types of Human Process are far too fluid and dynamic to be made part of an Enterprise BPM system - and tend to handled through email - yet another cause of email Information Overload…

Linking Documents and Process

August 7th, 2008 by Jacob Ukelson

I have been thinking about documents and their usage context in organizations. Knowing how a document is used is just as important as knowing the content, though today’s document repositories don’t really know the usage context for the documents they store. At best they and let user try make up the gap with tagging and descriptions. Most human centric organizational processes entail the use of various documents as a natural part of the process - either as input to the process (e.g. research or background) or output (e.g. a findings report).  So the link between documents and their process context is a natural one, and critical if you really want to understand the document.

So it is surprising to me that this hasn’t come up more as an issue in document management systems - the need to really connect documents and the flow of the human centric process that uses them - even if the process is an ad-hoc one executed (as most are) over email.

You could decide to implement all processes as a workflow in a document mangement system - but for many processes that would be overkill (especially the ad-hoc kind), would just take too long and require to many IT resources - not to mention that it would require the users learning a new way to do things. If you decide to keep the documents in a standard repository - then you lose the connection between the process that used or generated the documents - which means that you really can’t understand how the document is actually used in an organizational context…

Online Ad Targeting: Fine Grain Targeting vs. Coarse Grain Delivery

July 21st, 2008 by Jacob Ukelson

Behavioral ad targeting has been getting a lot of attention in the press lately, especially around the US Congress’ interest ing the technology. In general ad targeting of various shapes and forms is also becoming a busy space for startups - various types of targeting technologies trying to understand the users intent, and provide them with an appropriate advertisement.

When I looked a bit closer into what most of these ad targeting companies do, it turns out that after they have used whatever mechanism (contextual, behavioral, demographic, psychographic etc.) to decide who you are and what interests you, they translate this into one of a very small number of consumer segments, pick an ad for that segment and display it to you. So all that fancy computation upfront to provide a canned ad. Seems kinda of a waste. Wouldn’t it make more sense to create a personal, data driven ad (from one or more advertisers) to leverage that information? That would be the “holy-grail” of true 1-1 personalized advertising.

This growing impedance mismatch between the fine grain targeting ability of ad networks vs. the coarse grain delivery capability of advertisers is going “short-circuit” the ability of these targeting technologies to show their full potential.

eMail and Human Process Management

July 14th, 2008 by Jacob Ukelson

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.

Back to Blogging

July 14th, 2008 by Jacob Ukelson

It has been a long time since my last post -I guess I just couldn’t keep up the pace. Writing the blog is hard work, and I just couldn’t find the extra time to keep posting.

So now I’ll take another tack - I’ll try to keep things up to date with shorter, less elaborate posts more often. Lets see how long I can keep that up.

BTW - I finally received the eBook, the screen is gorgeous - very readable. I think it was a worthwhile purchase, even though it ended up costing me a lot more than I expected. If I was living in the US a Kindle would probably have been a better choice. The nicest thing about it is that you can take lots of different books with you anywhere, and if you live outside the US - gives you exponentially more book selection, and much lower price per book than you can find in physical bookstore. The main issue is with formats - there are many ebook formats out there, and different devices are compatible with different formats.

The “prosumer” experiment was interesting too. In today’s user generated content world, one irate customer can cause a lot of damage (by negative posts on blogs). I don’t know for sure, but I am guessing that all-in-all, trying to “contain” my complaints cost BooksOnBoard a lot more than if they would have just fixed or replaced my device.  That kind of irrational response fits very well with an excellent book I am reading (on my eBook of course) - Predictably Irrational by Dan Ariely.

Bad Customer Experience

May 13th, 2008 by Jacob Ukelson

This is the first time I am doing something like this, but I just had the absolutely worst customer experience I have ever had, and it was from two startups. The culprits are Bookeen and BooksonBoard. I decided to try an eBook to see how things work. i settled on a Bookeen Cybook (the Kindle wasn’t available, and I wanted to use it to read mostly PDF’s so I decided on the Cybook.)  Well, it was broken out of the box (though it took me over a month to try it out, I just didn’t have the time to get around to it). The first time I turned it on I was impressed with the resolution and was dying to try one of my books - but I couldn’t navigate - all the buttons seemed to be dead.

At first BooksonBoard were pleasant enough we spent about a week trying to diagnose the problem - recharge it, reinstall firmware. Finally I just asked for a refund. That is when they got nasty and told me that since it was over a week - they just don’t give refunds. period, even though the device was dead on arrival. After some nasty emails back and forth it seemed like the only way they were going to do anything was if I sent it back to Bookeen in France at my own expense.

So I sent it back, packed as they suggested. Today I finally get an email from Bookeen telling me that the screen was broken “either by a drop or pressure” and therefor wasn’t covered by warranty. yeah right. It seemed to me that the only thing that was working was the screen. Now I could pay another $130 and maybe it would work or just write it off. Those were the choices they gave me for a few hundred dollar device that never worked.

So what have they accomplished? They have one irate customer that will NEVER recommend them to anyone, and of course this negative blog post. I am not sure how they (Bookeen and BooksonBoard) think they will succeed with this level of customer service. They broke cardinal rule number 1 - the customer is always right.

This got me think how difficult it is to create a hardware based consumer electronics startup. The level of service they are expected to give just doesn’t jive with the level a startup can provide, unless you team with an experienced retail team. 

Loaded for Bear?

March 15th, 2008 by Jacob Ukelson

I follow quite a few blogs, especially in the startup and VC space, and what surprises more than anything is that not many are discussing the pending US (WW?) recession. I first posted on this in October 2007 (Subprime Mortgage Crisis and Startups)  but since then things have become a lot clearer, and a lot worse. In my opinion it is time to batten down the hatches and get ready to weather the storm.

What does that mean if you are a startup? Well, first off - if you are already funded and going to need to engage in a new round any time soon (say in the next 9, maybe even 12 months) - I would recommended moving your schedule up and doing it now.  It isn’t that the VC’s money will evaporate anytime soon, it is just that they will start being more cautious with investments, things will take longer and valuations will go down (as far as I can tell they already are). Right now most VCs don’t seem to be worrying too much about the upcoming recession - but sometime soon (I’ll guess sometime in the summer) they will - so use this time to your advantage.

If you are pre-seed, and haven’t already been funded, be prepared for a longer gestation period before you can reach the appropriate milestones to get to your next round of funding (especially if they have anything to do with customers, or market validation). In my opinion, you can just assume that anything you start now won’t have a market for about a year. That means that if you have any chance at all to get funding soon - do it now (perhaps at even a lower valuation), and use the rest of this year to build up your product and get ready for 2009.