Albert Einstein’s Other Theory

einstein

Albert Einstein said that doing the same thing over and over again and expecting a different outcome is the true definition of insanity.

Ok, so maybe Einstein wasn’t specifically talking about the industrial world.

But his “other theory,” does apply to business.

Consider This

AND you continue to do it hoping to see a significant rate of return on your investment — not only might it be a bit crazy, it’s just not profitable.

Think about which processes are being used every day in your company for work to flow from start to finish, in the hope of yielding huge profits.  As a key decision-maker in a company, you need to find the workflow process duplications and overall inefficiencies.

If Einstein were a businessman, he probably would have defined another theory of relativity:

Low Profit

Don’t let this equation be the sum of your business’ value!

Einstein’s theory states the underlying reasons for why workflow software is important for any organisation. Many of the core benefits have been previously discussed in the post 10 Benefits of Workflow. So if you’re not already using workflow software and are considering it, then it’s probably the right time to seriously start looking into it.

If you’re interested in more information about our workflow software please visit Web and Flo.

On naming software…

As mentioned in previous posts, we’re going through a process of launching a new product specifically designed for SMEs – which has gotten me thinking a lot about naming.  Many of our clients white-label Kontinuum – they develop workflow solutions within the Kontinuum engine, and give the configured solution their own branding which they then use within their organisations, or when re-selling the solution to their clients.  Sometimes, these names are brilliant – concise, catchy, and explain the app well.  So while I’m thinking about it, here are some things we consider when coming up with names for products:

1. Keep it simple – short, easy to remember, and easy to spell

“Everything should be made as simple as possible, but not simpler” – Albert Einstein

2. Make sure your name is unique – particularly in your industry (for all concepts), or across the board for all software.  This will help you to differentiate your offering without confusing the market or redirecting your users elsewhere.  This will also have the benefit of meaning you don’t have to compete with other companies or products for getting to page 1 on search engines, if you’re looking to re-sell your software

3. For the same reason, don’t name your product something too generic like a dictionary word – chances are you’ll need to add additional words (and therefore break rule 1) to explain what you do.  You’re also likely to end up low on any search ranking, at least for a while (notable exception – Amazon)

4. If possible, use the Meg Whitman rule and come up with a name that might be used as a verb (as in, “I’m going to google this”, “Can you xerox this for me”, etc)

“When people use your brand name as a verb, that is remarkable” – Meg Whitman

5. If you can’t get the .com; choose another name.  It’s just going to be too hard for users to find your site.

6. Don’t name your product something too specific that you may need to to change as your product evolves or pivots (Roses Only is a great brand, but I wonder how many of their gift baskets and fruit baskets they sell?  The name would detract anyone looking for those products, as you would assume they don’t sell them)

I’m wondering if anyone has any notable examples of, or exceptions to, the above rules – or any more to add.  Please comment if you do!

Say it aint Silo

Much of what we do in the BPM/Workflow space has to due with bridging the gap between business silos within organizations. All businesses of a certain size have them, and in the majority of cases they contribute to inefficiency. However since all businesses have them, are business silos not always a bad thing. Therefore what should you look for to determine when bridging a silo is just, a bridge to far.

Silos come into being for a number of reasons like: companies or generally hierarchical in nature, they may have had mergers and acquisitions, poor planning or just different requirements. Sometimes silos are formed instantly but generally they form over a period of time.

So when is a silo a good thing or at least not all bad?

Well in some cases similar IT systems may be replicated in various degrees within an organization but due to different requirements these may be a requirement. This could be related to the general cultural or geographic requirements of a silo.

Silos provide a level of security. They intrinsically act like firewalls.

Finally there is the possibility of information overload. Putting all the information in one place when the majority of information and features might be visible but inapplicable across the business silos is unwise.

It is important to consider when developing BPM applications what the negative effects will be for technology with respect to silo bridging. It is also important to consider the political effects as well but that is a blog for a different day.

Can business users make their own Workflow/BPM Applications

This is in reference to the following article:

http://kswenson.wordpress.com/2006/07/09/what-bpm-can-learn-from-a-spreadsheet/ 

 

Can business users make their own workflow applications, well yes they can. My girlfriend’s father who is an accountant with zero programming training created a simple 3 or 4 step BPM application using Kontinuum. I think the key word here is simple. Programmers are more likely to see the problems a little bit differently and their concerns of maintainability, reuse etc would not be at the forefront of the mind of a business user. This would mean that as workflow systems tend towards greater complexity the non-programmer would create a less and less cost effective solution.

As for the first question of Business office workers will never program software well they are already doing so. Not only in excel type applications but also in creating BPM applications.

Another counter argument is that the application is purpose built. Well every language was built with a purpose. Take C and Prolog. Built for different purposes. Are neither of them programming languages? If you submit that they are because ultimately they could achieve all the functionality of the other albeit in an often convoluted way well then couldn’t a BPM system deliver such functionality albeit in a more convoluted way?

As a final though some people have said that 3gl is not programming. OK why? Because it is to easy? Because you don’t have to type? The important part of programming is logic. If you can deliver to a computer that same logic through dragging and dropping something as opposed to typing it out what should it matter. If not then isn’t 2gl not programming either? Should we real programmers go back to binary?