Showing posts with label BPM. Show all posts
Showing posts with label BPM. Show all posts

Thursday, May 14, 2009

Is BPM counter cyclical?

There’s a theory going around that has probably been mentioned enough times now to become a mainstream view. The theory is this – BPM is counter cyclical. And the reasons put forth for it are this. During a recession, companies are looking to cut costs and one way to achieve this is by purchasing and implementing BPM software. BPM promises to improve process efficiency thus reducing costs.

It’s a persuasive argument, if a little simplistic, but is it true? To tell you the truth I have no idea. Rashid Khan argues it’s not true and the only arguments I’ve seen that BPM is counter cyclical seem to have come directly or indirectly from BPM vendors. Certainly something that promises to offer a significant reduction in costs is going to be attractive but BPM software is generally an expensive purchase (although there are free options starting to appear) and then there are costs involved in actually getting it up and running. No single company’s processes are exactly the same as another so some analysis and development will be required. And processes change, so there are on-going costs incurred. Finally, it’s difficult to quantify how much money will be saved by implementing BPM. I’ve seen some impressive figures for savings made, but will those figures be replicated in your organisation? There are so many variables involved, it’s probably impossible to know. Again, that may make it difficult to justify the up front cost.    

Next, some anecdotal evidence. The Lombardi conference was cancelled and became a virtual event, but the Metastorm conference was well attended, so it’s difficult to draw any conclusion from that. Metastorm claim their revenues have increased by 16% over the past year which isn’t explosive growth, but any kind of increase should be considered a good thing at the moment. The company I work for has certainly not been unaffected by the downturn but we are still managing to keep our head above water.

That all said, BPM isn’t going away. And if it isn’t counter cyclical, that won’t necessarily be a bad thing. Perhaps, finally, we might see some consolidation in the area. Some of the weaker companies may disappear or merge and the stronger companies can gain more market share and thus have more money when the recovery comes (whenever that maybe) to produce even better software.

Of course, if you are thinking about or are actively implementing BPM in your organisation, Process Mapping is here to help.

Sunday, February 22, 2009

BPM for business users

Prototype activity From my time on the Metastorm forums one thing is obvious, most people implementing Metastorm solutions are not business people. Mostly they are technical people, with a few not so technical people. And it’s generally the not so technical people who are having the biggest problems getting to grips with the product. Is that a failing of the software? I’d say not, although it could arguably be a failing of the marketing of the software, which like most BPM products suggests a non technical person can use it from start to finish to produce a working system.

This situation reminds me of other areas of software development, like the development of websites, or application development. A while ago, people thought anyone with a copy of FrontPage could develop their own website or anyone with a copy of VB could knock together a working application. But these other areas have matured enough to recognise that actually those pesky developers are still required (or to put it another way, designers can’t code and coders can’t design) and the development environments are now set up in such a way that the designers can work with the coders to produce a working system. For a website, the designer can produce a HTML layout that looks good and then the coder can add the required code so it does something. In the world of Windows development we are moving to WPF and other technologies where the layout is separated from the code, so the designer can produce the pretty screens and the coder can then add code to do stuff without both sides stepping on each others toes too much.

And for me, that’s the approach that BPM will have to take at some point, realising that the business people can’t code and the coders don’t understand the business, so trying to put only one of these people in charge of the BPM system will never fly. I think Windows Workflow is a step in the right direction with its ability to create custom activities. The coder can create all the required custom activities and then the business person can plug these together like Lego as required. Or this could work in the opposite direction, where the business user produces their process and adds dummy activities where they need functionality to be implemented and the coder goes off and creates the required activities.

With that in mind, I created a simple PrototypeActivity that can be added to a workflow and lets the user specify the inputs and outputs that will be need to be implemented. The screenshot shows how it looks in operation (although a proper implementation would probably provide a better user interface). The code is below.

  public enum PropertyDirection
  {
    In,
    Out,
    InOut
  }

  public class ActivityProperty
  {
    private string propertyName = "";
    public string PropertyName
    {
      get { return propertyName; }
      set { propertyName = value; }
    }

    private string description;
    public string Description
    {
      get { return description; }
      set { description = value; }
    }

    private PropertyDirection direction;
    public PropertyDirection Direction
    {
      get { return direction; }
      set { direction = value; }
    }

    public override string ToString()
    {
      return direction.ToString() + " - " + propertyName.ToString();
    }
  }

  public class PrototypeActivity: Activity
  {
    public static DependencyProperty PropertiesProperty =
      DependencyProperty.Register("Properties", typeof(ActivityProperty[]), typeof(PrototypeActivity));

    [DesignerSerializationVisibility(DesignerSerializationVisibility.Visible)]
    [Browsable(true)]
    [Description("The properties the activity requires")]
    public ActivityProperty[] Properties
    {
      get
      {
        return ((ActivityProperty[])(base.GetValue(PrototypeActivity.PropertiesProperty)));
      }
      set
      {
        base.SetValue(PrototypeActivity.PropertiesProperty, value);
      }
    }
  }

Sunday, December 14, 2008

Revenue models for free software

I have no ideological belief that software should be free, but it certainly seems to be an increasingly prevalent model for software.  Since I don't run my own software company the code I produce doesn't have pay the bills. But although I enjoy writing it, in an ideal world I'd still like to make some kind of income from my work. Probably my biggest piece of code that I've given away has been the FreeFlow library and Administrator, that can be used with Metastorm's BPM product. I've tried out a few different revenue generation techniques with varying degrees of success.

Sell the source - This was the initial model, let anyone download the binaries but charge for the source. It worked reasonably well for the FreeFlow library, which is used by developers to talk to the Metastorm engine. I guess developers are keen to get hold of the source for libraries they are using, to modify for their own needs and reduce the risk if the developer disappears. Unfortunately Metastorm introduced their own .NET library and as time has gone on there's been a lot more interest in the standalone FreeFlow Administrator application. With this, I suspect less people care about the code since if I disappear it won't actually affect their own applications, so sales of the source code have dropped off.

Website advertising - There's been advertising on the FreeFlow website for a long while and I've made a bit of spending money from it, but that's all. One positive of writing software for a BPM product is that most of the ads are for competing BPM products which seem to earn a good amount of money. The downside is that Metastorm is just one of many BPM companies and BPM is still a fairly niche area so I don't get a massive number of visitors to the site.

Donations - This is my latest attempt at earning a bit of cash. The website and the FreeFlow Administrator now have 'Donation' buttons. So far I've not earned anything from this at all. I'm not hugely surprised. If I'm using a free piece of software I very rarely donate any money. If it's shareware, I'm unlikely to pay for the full version even if it has nag screens (WinZip anyone?). The exception to this is SmartFTP, which I paid for because it needed re-installing every few months and it's actually a nice bit of software.

Ads in the application - I haven't tried this yet and I'm not even sure how ads can be added to a desktop application but it seems to be the path FeedDemon is going down. I may wait and see how well it goes for that software and my own donations before going down the same route. One of the nice advantages of not needing to earn any money from my software is I can try out different models for as long as I want before trying out something else.

A buy out - There has been interest from people wishing to buy FreeFlow off me but there have been no concrete offers as yet. I'd definitely consider a serious offer. Even though I have some emotional attachment to the code I've written I'm not dumb enough to refuse a reasonable amount of money if somebody offered it. Unfortunately as this is a niche product, I can't really see there being a huge number of suitors... 

In conclusion, I think if I was starting from scratch I'd probably try writing software with a potentially wider audience. Something like TimeSnapper, which is of use to almost anybody. And I'd probably try a similar pricing model to their software, a basic free version and a more feature-rich professional version. Or an ad-sponsored free version and a paid-for non-ads version. Now I just have to figure out what that software would be...

Saturday, March 08, 2008

The big BPM lie

I've been looking at a few Business Process Management tools on and off and I've noticed something that most of them share in common, they like to brag that no coding is required to get your BPM solution in place.Whilst a laudable aim, I doubt very much that it can be met, especially when integration with other products is required. And integration is one of the key ingredients to a successful BPM implementation.

The stock answer to integration is the use of web services. And they could be the answer. They are a standard after all, but unfortunately each development platform seem to implement these standards slightly differently. I've had much fun calling web services authored in Perl and Java from .NET. And that was using code, rather than any web service integration abstraction piece provided by a BPM product, which would almost certainly have made other assumptions about how web services work. Almost every abstraction is leaky. And when an abstraction is leaky, it is necessary to drop down to the next lower abstraction, which is code in this case. And if the abstraction isn't leaky, then the BPM vendor must have produced some kind of general integration technology which is actually pretty damn useful on its own, so why aren't they selling that?

And when a BPM vendor says no code is necessary, it means that it's likely its story for writing code in their development environment is probably not going to be as good as it could be. After all, you'll never need it, right?

To a certain extent I can understand this emphasis on a no code solution. After all, if code was required to implement even a basic BPM solution using their product then the BPM software wouldn't be providing much value.

This is one reason why I love Windows Workflow. It is unashamedly a development tool and doesn't shy away from code. OK, it's not a fully-fledged BPM tool, but it is certainly possible for a BPM product to be built on top of it. Workflows can be designed without code, but when it's needed, a developer can come along and produce a custom activity to do whatever integration is required. This seems like the perfect solution and I hope this is how BPM products will be designed in future.