Been quiet here, but not at all idle. Thingamy stuff afoot.
We have added developers to our team, Ajax to the thingamy interfaces, more features and started some crazy under-the-hood tinkering to move the message "Now go run Germany!" into "Now go run China!".
User friendliness, the current focus but never ending quest is not easy. Let me give you an idea what paths we're testing. Emphasis on "testing".
1) Ease of use: In the sense of interface speed and simplicity. Ajax is certainly helpful and we did a reasonable skip forward with latest build.
2) Understand what you see: The terms. Given up on finding anything precise. That does not exist unless all thinks the same way, so forget that. Better is terms that gives a hint, that does not precisely define something else. So string is text. Object is Thing. Container is Place. And Tara's "String? That's what the cat plays with" could be a thing of the past.
Then with terms-as-hints one must be able to try it out, click a bit around and go "Ah! That's how it works" without too much effort.
3) Understanding the concept: Now that is definitely not easy when you're trying to break all the rules. So let's see what we're trying here... build and run a business... whatever you say, that should not be complicated as such. I would say it gets complicated because we make it complicated, so let's try not to. That would be cheeky statement # 1.
This is the first interface when you enter the Business Model Builder, more cheekiness afoot here (from a hospital demo this):
"What, strategy? I wanted to build a run-your-business system here. What's this?"
But, starting to build a Business Model without a clear and simple strategy makes it hard to get anywhere. Even if it is for a small support team in a corner office.
It's like choosing mode of transportation before you know where you're going.
Be careful not to take the strategy for granted, sometimes I hear and see (browse around on corporate web sites and look at their strategy / vision statements!) strategies that hints to (using the transportation analogy) that many firms are more interested in "Sunday outings" as in "driving around for the mere pleasure of driving". Cheekiness # 3.
It does not have to be very precise - banal, simple and the "gist of it" is better. Sometimes slogans are closer to useful than vision statements - Nike's "Just do it!" and Nokia's "Connecting people" are among my favourites. Nokia's covers even it's former product lines of car tires and wellies!
[Glad you asked; thingamy is about helping you to "run your business so you can beat the shit out of your competition kick ass"... at least that's the gist of it.]
So in this interface you note why you're doing what you're supposed to do, why the heck you have hired people and opened an office or put together that group, department or team - the "what value shall I/they/we deliver".
In this example of a Hospital I set it to be "Cure medical conditions", banal but true.
Then you go about building your Business Model step by step, entering the tabs from left to right like this:
Things: Now you know what "main thing-type" you must define - "Medical Condition" - which you can use to stamp out unique things every time a patient arrives with a broken arm or whatever. Then send those medical condition things into a flow to cure it.
When you have the "main thing" you obviously will think of "helping things" to define here - "Medication", "X-ray", "Blood test", "Surgery" and a "Patient" of course.
Places: Quite useful so you can find the medication package or a bed.
Tags: Another useful feature to add knowledge to the "things" making finding during a workflow easier.
Flows: Now you have the blocks to build those all-important work-flows. Where to start? Curing a medical condition of course, that's the "main flow". Then add "help flows" later.
The "main flow" - receive the patient and ask him for his name and add details to the "thing" that will as of now represent him in the system, the "Patient" thing. Then add some information to the "Medical condition" "thing", what's wrong, when did it happen. With that in hand the receptionist should be able to choose the MD and set time for an appointment. There the chosen MD will get the information up on his screen (simple display of the pertinent "things") and fields to fill out so he can add more information to the "Medical condition" "thing". Then he will choose what tests to undertake and the flows goes on and on in loops and branches and whatnot until the ultimate goal is reached "Medical condition is cured!" Then add some help / admin / back office flows like procurement, adding history, whatever.
Now it would be cool to make use of the data captured by the flow - that's when the Accounts and Reports comes in. Just define what's needed in templates and give access to whoever to whatever reports they need / want / is allowed to see.
Now, that's all there is to it. Just "Strategy" -> "Things" -> "Flows" plus a few helpers.
Thomas has a great post here which reminded me about something I've been mulling over lately:
Process or procedure, systematic or ad-hoc, structured or framework, pipeline or riverbed?
Ad-hoc, now that is no process or what...
On one side you have the processes Thomas describes as the "process broccoli" - no nonsense, precise, repetitive. The stuff that builds the iPods and BMWs of this world. The pipelines.
Then we have the rest. Yep, the rest. Everything is a process, "a series of steps", a sequence. Even if the "particular end" to be achieved is iffy.
If we meet over a beer and engage in a conversation it is a sequence. Talk, listen, talk, listen... a procedure we adhere to so the flow flows and we're not seen as impolite. A culture based riverbed.
The farmer has some rough lines of what he has to do, then he must adjust according to the weather. He's operating by the riverbed principle. An experience based riverbed.
Then the receptionist - "what could I help you with?" would usually be his starting point before choosing next step down a wide procedural tree with many branches. Organisational hierarchy based riverbed.
Ditto for the day trader, the MD, the rest of us. Rough framework to the sequences, lots of choices underway. Culture, experience and hierarchies as riverbeds.
So far so good, we all know this and we can live with it. Except we also know that to base business and efficient use of resources (including our own time) on culture, experience and hierarchies as the suppliers of process structure is far from perfect. The methods are fraught with issues and hopelessly rigid. They're really bad at it in fact. Really, really bad.
First stab to solve the issue was by real hard technology like assembly lines. But the technology was limited to very strict processes. Like building cars. Real pipelines.
Next out was the softer kind of technology, IT. But software is only a model, and as long as it models the world as it is (pipeliney or iffy) it merely ends up as another pipeline or nothing at all. Assembly line thinking applied to a few other processes in the first instance.
That worked well for the pipeliney processes, even beyond the real nuts and bolts assembly lines. Still, most of what we're doing, even at work, does not fit that model.
Because a pipeline cannot act as a riverbed.
(A note: But a riverbed can act as a pipeline, just narrow it down and add some barriers and checkpoints and it behaves like a pipeline!)
The big suppliers of pipeliney systems (names politely withheld) cheekily calls the result of this phenomena their "white-spaces", then selling that as a positive opportunity for partners... :)
Not happy, the users implemented wikis and other collaboration tools and developers stretched the webby stuff to Web/Office 2.0 prominence so as to relieve some of the white-space pressure.
Now, any riverbeds there? Nah, but plenty of pools.
Like covering "white-spaces" with "white sheets".
Did I mention that we're tinkering with the issue? Something riverbed'ish... ;)
Nope, not the Open Source software movement this time, rather an "open up your sources to become better" angle to business.
James had a great post over here - comparing the attitude to bloggers amongst the enterprise software biggies.
As you know I was blown away by SAP's attitude (and the practical effort indeed, hey, they even organised and paid for my hotel and travel!) when I was at the SAP TechEd in Amsterdam a few weeks ago. I mean, I'm not even an analyst (like James), just a humble blogger with some software that - by some good stretch of imagination - could even be thinking of nibbling at their customers.
Still they had all doors wide open and I was able to discuss anything with anybody I met. That's for me the "future attitude now".
Kind of funny how it works - if they'd been closed and old-hat corporate cards-close-to-chest I would have applied the same attitude. But nope, SAP was completely transparent so I put no lid on when discussing how we (thingamy) radically approach some of the same enterprise issues, even in the same detail as they offered. Hopefully it was of some small value for some of the SAPpies I had the fortune to talk to, if not I owe them one :)
Indeed, I'm currently having a great ongoing conceptual discussion with a representative of another potential "competitor" - and lo and behold, more practical results and clarifications of my own thinking. But I'm sure that my input has at least some small interest to my friend over there, otherwise the discussion would peter out or what?
That's how "competition" should be - compete, work together, same diff - the end user gains.
Or put in other words, give and receive beats old hat secretive paranoia!