flow and context

Flow is context. Flow is relationships. Flow is knowledge.

Howz that again?

Context (Oxford American Dictionary):

"The circumstances that form the setting for en event, statement or idea and in terms in which it can be fully understood and addressed."

Relationship (Oxford):

"The way in which two or more concepts, objects or ideas are connected, or the state of being connected."

Knowledge (freely gleaned and distilled from Plato):

"How objects or subjects relate to other objects or subjects."

Ad hoc events and you're completely dependent on search and ad hoc communication: "What's meant by this?", "Is this expense relevant?" or "Who could take this ball and run with it?"

Searching the web, contacting the people responsible for the trip or searching the firm's employee roster or supplier list.

That's how things are done today. Thus focus is on bettering the crutches that support the less-than-perfect ways: Office applications, communication tools, search engines...

Now, how about fixing the root, not pruning the leaves?

An event in a flow: You know why it's there, you know what has happened so far, you know where it's going, you would get all pertinent information (if not you'll have that fixed for next round!).

You'll have the context, the relationships and the knowledge inherently delivered with the event. But only if it's a part of a flow.

So, use the flow and make a quantum leap :)

Comments

[peter]

well, this is true, but how do you accommodate all the different flows (and/or how you mine out the existing flows) that do happen in an organisation?
Also, what happens if someone does stuff "offline" ? :)

[sig]

Peter,

glad you asked!
That is precisely what we're trying to do with our "Thingamy" project (http://thingamy.com) :)

That webpage is still pretty enigmatic though, but your question says it all - that is exactly what our system will try to do, accomodate (and run) the flows of any organisation (including sorting out the resources and deliver whatever reports you might need)!

[Dennis Howlett]

so it's a bpm/bpo style engine with functional components that can be attached and which will have an immediate, optimised understanding of all others components in the system?

[peter]

sounds interesting.. (I read your blog for a while...) Your website doesn't really tell any exact stuff on what it really does (besides that it does everything :) and what for example I, as an average user see from it... and how it affects the way I do my job.

[sig]

Well guys, lemmesee... yes and no to Dennis, as always it's about "what's in a word":

"Business processes" are usually quite limited, mostly due to the departementalisation of hierarchies.

We see absolutely everything that happens within and outside and organisation as one-single-flow, consisting of events, transactions and instructions all nicely linked (thus delivering a workflow), can be built from any point in all directions, can have loops, forks and be dynamic during a run.

Those "building blocks" (events etc.) uses defined classes to produce objects that again can be used by "report templates" built in an interface to deliver whatever your heart desires - accounting, lists, nice layouts, analysis, history, snapshots, overview of process, whatever.

All of this can be changed, tweaked and made better while system is live. All is kept forever thus history is available as well as the basics for Sarbanes-Oxley, Health requirements, Basel II and hopefully anything coming in the future.

The system can thus replace any application used in an organisation today. It does not need a hierarchy so it can even replace that.

At the same time it can mimic a hierarchy and any known application - thus you can start from where you are and move wherever you want to go.

Peter, how would it affect you as a user? Well, workflow would be easier to grasp, pertinent information would always be delivered when you need it, transparency (i.e. you may be allowed to see how others are doing :), managers could be redundant (leaders we'll need), hierarchies gone, quantum leaps in resource-use-efficiency and no contest in winning the race ;)

Hehe, no guarantees to all that - that was my imagination going wild - but that is the only thing I actually can promise: The system could stir some creative business models and ways to run your business far beyond what's accepted as the-way-to-do-it!

"Best practices", pffttt I say :D

[peter]

ahha, I see.. So I can imagine this now as a.. hmmm, lemmesay development framework, where someone can build business processes, reports, GUIs, whatever that's needed for it to be usable. This Thingamy stuff then provides a transaction-engine that manages links and data flow between the events. So when I let's say deploy this, I will have to do (or have someone to do..) lots of work to move the business over to the new system. (or do the transition slowly...)

On the business process part, yes, today those are pretty limited, but we do limit them, as we try to replicate the hierarchies.. And managers now are needed to 'kick butt' to move things, but surely, someone has to define these processes, am I right? (or I can start sending messages and mess around, and the system then finds out the flow and optimizes? .. I think it's a long shot :)

[sig]

Peter, precisely!

*patting own back for being good pedagogic* :)

Your "lots of work to move the business over to the new system" and "someone has to define these processes" are interesting:

Yes, you're right on both counts, but something "funny" starts when you do this - your mind gets creative as you have to conceptualise reality, just like we all get ideas when tinkering with budgets or whatnot in a spreadsheet.

Hope is that some processes and data structures will be bettered simply because you have to revisit them in a very structured format. Then add that you may add structure to processes and data that nobody ever bothered to structure... all in all well worth the effort in itself, I believe :)

[peter]

sounds nice. How'd you do it? :) Really, just to get a grasp of it: how do you define the "building blocks" and "classes"? Is there only one kind of object that can be anything, or you can have (and how?) as many object types as you need? (one for meetings, one for a balance sheet?)

[sig]

Well, classes (and thus objects) are used throughout, but the classes you can build and change while system is live are limited to anything you need to have "properties" on, resources, people, any object or where you want to amass information, say details about a person, a transaction, health records...

And you can "nest" the classes so a person's health records could consist of many classes making it easier to split who sees what for example, or use the classes separately in different events (reception filling out personal details and insurance stuff while an MD or a lab technician would fill in other information of course).

Then comes "report templates" where you can build templates delivering whatever report using the classes and their properties - inventory lists, patient journals, whatever, or accounting reports.

Accounting is quite a bit different from what you would be used to as it maps transactions to accounts (when you build the accounts, say a balance sheet, P&L etc) thus enabling parallel GAAPs to run at same time, or changes to be made directly applied to all earlier years (translate all previous years from UK GAAP to US GAAP in a dayts work).
It uses the raw data and produces a report on the fly, thus you can get a balance sheet for January 3rd, 2003 10.24 AM or for same day at 4.16 PM if that is of interest :)