« Community is Open Source: On SAP Developer and Business Process Communities. | Main | complexity and complication »


phil jones

Totally agree that increasingly enterprise software is used to police the process rules. And equally that there's a huge demand from customers (ie. NOT users) of enterprise software to make sure that the software gets these rules "just right".

That's the challenge. I'm convinced that companies that take advantage of new software to throw away their old processes will have a huge advantage.

The problem is convincing them ... and I'm thinking that that's largely a matter of the existing internal divisions between who buys software, who specifies it, who uses it.

As long as "procuring software" is a little insular process within an organization which is given a mandate : "go and buy software" and this is completely independent of "let's think about our internal processes" companies are in trouble. But so are *new* enterprise software vendors.

Perhaps one thing vendors can do is to provide some little "what-if" process modelling tools (widgets) on the web-site of the company selling the software, so potential buyers can play around with process remodelling and understand the potential.


Phil, you're absolutely spot on that not enough questions are asked as to "why?" (BTW, goes for most any purchase I suspect...)

Suspect this is a leftover from the days software were mere support tools to other frameworks. OK, most still is... but if (business model) framework then suddenly Enterprise Software would be impossible to split from strategy.

Agree to your last point as well, some way the actual user can play around and perhaps even use.

But as mentioned above, what if the system becomes a framework then as you say, the people close to the strategy would be the users... and that certainly injects some very new requirements into the design and ease of entry :)

What we're talking about here would be close to the (unintended?) sell-in mechanism of web/office 2.0 products. Let users use, apply creativity, find value then move to convince buying powers to buy with proof in hand. Now how to design so the powers close to strategy wants to spend time on playing... hmm...

Ed Matthews

Here is a set of categories, if not a framework, for analyzing the business question, "Why isn't this repetitive action automated?" or alternately, "Why are my costs so high?"

Assigning ownership

ERP manual work and associated costs revolve around these categories, which need often to be repetitive, to run in parallel with each other, and to have outputs for different audiences.

For example, while a transactional customer service person is managing an order, the system should be journaling what is being done and outputting that to the HR / Mgr / Business Analyst, etc.

Every ERP should have a base "ticket" module (Request Tracker (RT), Jira, etc) that can handle the unstructured human-based work, and the binary files.

These modules typically handle the ideas of owner, workflow status, journaling, attachments, etc. and often better than ERP does, because they were designed for Gathering and Sharing, and let humans do the Categorizing and Assigning, tasks which ERP automates when it can but also rigidly and often incorrectly enforces.

Along side of Tickets, but never entirely replacing it, one builds the structured data and the business rules incrementally as he figures out what's really going on with the manual work.

So, first work manually with a tool that records what people are doing. Analyze the records. Add structure. Add automation. Repeat.

In the web world, the ticket systems need to talk to each other; there should be no more application silos. Interestingly, Google, Yahoo, etc. have not put up ticket systems to date. We shall see what the gPhone / Android stack brings in 2008. Some vendors are Zoho, RT and Hiveminder, Atlassian/Jira, QuickBase. Security remains an issue for hosted systems.

Take the ending for what you will, the early chapters of this short story describe how humans are directed by and become gathering agents for an ERP:



agree to your suggestion - although it raises (or rather should raise!) the question:

Gathering of process information for the purpose of automating/structuring entails an acceptance of the current processes.

That, as can be seen from most of my posts herein, is where I respectfully differ - in the name of process innovation (the highest, increasingly so, contributor to productivity growth) one needs to revisit the processes, question them and if need be change them altogether. Current processes are after all a result of former technologies (pen, paper, feet, ear-to-ear) and that alone should give a hint that there is much room for innovation.

And the best way to innovate is often to discard former ways for a moment, revisit the underlying principles and objectives for the organisation - rebuild from there, test, rebuild, rinse and repeat.

Of course one might end up with the age old process, but rethinking/revisiting is a must anyway to establish if current process design is really the best.

And then do the same next week, now with some experience ;)

The comments to this entry are closed.

My Photo


  • Phone: +33 6 8887 9944
    Skype: sigurd.rinde
    iChat/AIM: sigrind52

Tweet this

Thingamy sites

  • Main site
  • Concept site

Tittin's blog


Enterprise Irregulars


Twitter Updates

    follow me on Twitter


    • Alltop, all the cool kids (and me)


    Blog powered by Typepad
    Member since 01/2005