I happen to be the tech lead of a team that builds internal tools for an "enterprise" company primarily using Django and Flask. Build it and then show the business how it is useful. Sadly, that means you might need to write a lot of high quality docs or high quality clients (if you write an api). I tend to favor "api first" development.

Our company's bread and butter is low latency stuff and we're a small team of webdevs who exist in the IT side of the company, but code fulltime. I quite enjoy it actually.

For some background on business process / workflow automation, a few good books to review would include:

http://www.amazon.com/Essential-Business-Process-Modeling-Mi...

http://www.amazon.com/Fundamentals-Business-Process-Manageme...

http://www.amazon.com/Smart-Enough-Systems-Competitive-Autom...

http://www.amazon.com/Social-BPM-Bpm-Workflow-Handbook/dp/14...

http://www.amazon.com/iBPMS-Intelligent-Systems-Workflow-Han...

http://www.amazon.com/Real-Life-BPMN-Analyze-Automate-Proces...

That said... for starters, I'd back up to the issue of truly understanding the business need you're trying to address, and figure out a methodology for mapping the technological capabilities you will implement, to the business strategy. To that end, I'm a fan of a technique called "capability cases", and actually wrote a series of blog posts on that topic a while back. I'll refer you there for more on that topic:

http://fogbeam.blogspot.com/2013/01/why-capability-cases-are...

http://fogbeam.blogspot.com/2013/02/so-what-is-capability-ca...

http://fogbeam.blogspot.com/2013/05/capability-cases-part-th...

The other positive thing about the Capability Cases methodology is that it helps IT people learn to "speak the language" of LOB executives (and, to some extent, vice versa, if everybody buys in), and helps bridge that gap between "the business side of things" and "the IT side of things".

Anyway, if you get through all that and decide that some sort of BPM system is for you, there are a handful of high quality, popular, Open Source BPM engines out there that you could consider. If nothing else, they could enable you to get to a good POC quickly and without spending a bazillion dollars. One popular option is Activiti:

http://www.activiti.org

It uses the industry standing BPMN2 notation. Stay away from anything that mentions BPEL, and stay away from Oracle products. Especially Oracle products that involve BPEL.

Depending on how complex your needs are, you might not actually need a dedicated BPM / workflow engine. In that case, you could certainly code up automation code in any general purpose language of choice. But be careful of going down the path where you wind up rebuilding the wheel.

I'd also advocate taking a careful look at the idea of "Social BPM", which focuses on making BPM systems more flexible and less rigid, and introducing aspects involving social connections between humans.

I'm not trying to be overly self-promotional here, but I will refer you again to a couple of posts I have previously written on this subject, which may be of use to you:

http://fogbeam.blogspot.com/2013/05/social-events-bpm-oh-my-...

http://fogbeam.blogspot.com/2014/02/on-solving-social-aspect...

Like I said, this is a big topic. I could talk about this stuff for days on end, or until you died from boredom. :-)

Seriously though, if I can be of any further assistance, feel free to drop me an email.

I will likely code up disparate solutions for various problems first i.e. asset management, performance analytics, interactive dashboard etc. As much as I want to think at architectural level, I better show some quick results while learning more at the sides.

I'll be happy to drop you email later, after I've done some homework. :)

Common web frameworks like django or flask solves only technical problem related to HTTP/Client/Server functionality and nothing related to business logic organization except simple CRUD support.

It works pretty well if you going to create data entry applications for your business. Data entry applications allows end users to enter the data and do some queries and reporting. Basically you are offer for end user a set of forms for data entry, grid for end user queries and set of reports for things that couldn’t be achieved with simple grid filtering.

The usage pattern for worker is to enter the data, run the query/report and decide what to do next. This style of applications allows unlimited ways for interaction for end users, and adopts many scenarios.

But very fast it became not enough. The breakpoint happens when you came with idea, that you need something like `STATE` or `STATUS` field for one of you entity. This probably happens when you try to organize workers pipeline and collaboration.

And this ruins your well designed CRUD application. Mix of hidden state changes and crazy querying randomly scattered over the code makes hard to have a whole picture what really happens. After a half of the year, team of 5 developers could produce working but cluttered application that really hard to change to adopt new business process requirements.

The core problem that common web MVC pattern have nothing related to people collaboration. Fortunately there was a lot of research in this field, starting from 198x.

And the answer is - we need an explicit workflow layer (yeah, so pythonic)

You can take a look to http://www.workflowpatterns.com/ It’s pretty formal and hard to read, but it contains set of common patterns that happens when you trying to describe people workflow.

From historic point of view, there was discussion - what is the best way to represent people collaboration visually, what building blocks should be used and etc. In the 2004 there was several popular approaches for this like ebXML, BPEL, and many other formats.

At the 2014 we have the answer - only BPMN products became successful with the time. I think you will not very surprised with this fact, if you will know that BPMN is the only format designed for understanding by humans first. Other formats was designed like bad visual programming language and they are failed.

The core difference of BPMN that you have a gate nodes explicitly separated out of task nodes. This give you unlimited amount of flexibility, and most systems allows to skilled programmer develop very custom gate logic to accommodate all process requirements, embedded into reusable flow building block.

And the last part. The rise of workflow systems happens in the 200x. There was the time when UI-only programs declared as the way to happy user experience. Missing UI tools for system administration was declared as main problem of Linux operation system. Nowadays, UI for administration mostly failed. Today is the rise of script languages like Chef, Salt, Puppet, and DevOps as profession for system administration.

This sort of things became happens even with existing workflow tools, like jPBM based http://camunda.org/

I believe that should happens with any existing workflow software. With good designed library or language for workflow specification, developing application would be faster than any ui programming.

So, as the result of thoughts described above, Viewflow is the library that offers an additional layer for django web framework allows explicitly specify people workflow and takes out the workflow logic from django views.

You can take a look for shipment views example, when I start i didn’t expect that so complex workflow could be exality extracted out of the views - https://github.com/viewflow/viewflow/blob/master/tests/examp...

The future of workflow looks like we will have not only well specified business process but mix of process and cases to accommodate best things from data entry and workflow application styles. There is even existing standard for this - CMMN. And it looks like it would be very soon implemented in many workflow tools.