1. Run workflows and processes that no other can.
On one hand we have:
A procurement process, the HR department's hiring process, order taking, or any project - all well structured Business Processes, the typical domain of the big legacy systems or focused project management systems.
That's what we call Business Processes. The important stuff. IT stuff for grown ups.
On the other hand we have:
A desperate call from a chap in the field when a supplier does not show up, a router that goes whirr-kaplunk, or the back and forth of mails prior to getting that big project up on rails.
All run and supported by Monday morning meetings, boss meddling, e-mail, faxes, phone calls and to-do lists.
The business processes that's not even called Business Process. The process orphans. The nuisance. The stuff that actually take most of our time.
What I'd call Business Practices.
I wonder what the gain would be if the Practices could be as efficiently handled as the proper Processes?
A lot? A whooping gigantic leap!
Let me keep it simple and divide process types into two groups:
- The Easily Repeatable Process (ERP to us)
Examples: Production, procurement, HR processes, distribution and sales and marketing processes.
Supported by: ERP, CRM, HCM, PLM, SCM, SRM and BPxx systems.
Intellectual Capital: Big data repositories, data mining systems on top.
[Note: About 30% of the world GDP is created by these types of processes.]
- The Barely Repeatable Process (BRP)
Examples: Services, support, health, government, education and all those other "people" processes.
Supported by: To-do lists, fax-mail-phone, meetings and management involvement. Plus a dash of "collaboration" tools.
Intellectual Capital: Data (if any) spread in unreadable form all over the place, IC mostly entrusted to individuals.
[Note: About 64% of the world GDP is created by these types of processes. That's more than twice the ERP wealth creation while being almost untouched by IT based process systems.]
Thingamy is created from the bottom up to handle BRP and does it with great success. Add that ERP is a subset of BRP hence Thingamy can handle ERP very well as well, while systems made for ERP cannot do BRP, and that goes for all current enterprise software.
2. Paradigm shift on steroids.
In 1726 Daniel Defoe wrote "things as certain as death and taxes", today you could add another set of "unavoidable and certain work annoyances":
- Awaiting tasks from superiors
- Distributing tasks to subordinates
- Discussing these tasks to get more knowledge and clarify
- Looking for lost Emails
- Unsolicited calls
- Searching for information
- Shuffling paper or looking for paper, documents and forms
- Reconciling same documents and forms
- Meetings full of politics and work distribution
- Fretting over deadlines
- Planning work
- Updating plans
- Keeping to-do lists up to date
What percentage of your daily time would that be? 30%? 40%? 50%? 60%?
[Two reports out there stipulate 55% and 75% respectively.]
All of the above have no other purpose than "frameworking" your own (and sometimes other's) work flow. And a framework is a must, no flow of any kind can exist without a framework, like a river needs a riverbed. Even your to-do list or those Monday morning meetings are part of that riverbed.
What do you think the Industrial Revolution was about? Some was pure replacement of muscle power, but mostly it was people-work framework replacing mulling around in the workshop. Mr. Ford used a simple and tangible framework; the assembly line. Within six months building a car went from 70 man hours to 7.
Time to repeat that feat, now for all the not-so-linear BRPs of our offices, services, health, governments and education that stands for 64% of world wide GDP. That would indeed be an "industrial revolution on steroids".
[McKinsey says 60%...]
And that is precisely what Thingamy can do.
The positioned and powerful will protest but less annoying and more meaningful work might ensue, and if you're a shareholder in any firm, a tax payer or a sustainable, use-less-resources kind of person you will rejoice.
3. 1000 times less complex.
A swamp named complexity, that's what current enterprise software is waddling into.
The source of the complexity is easy to find; it's the wrong modelling method mostly thanks to some gentlemen in Venice 515 years ago.
Let's analyse, starting with reality where a widget is a widget. One object.
Add "distance management" of the widget in a widget producing or consuming organisation and the double-entry bookkeeping monster roars (hence Venice), requiring precise representation of each and every transaction.
Every order, every task, every move, every change of colour or bent ear - all must be properly documented, then entered into the books or system.
In that model each widget is represented by invoices, purchase orders, sales orders, work orders, bills of lading, journals and reports. The widget itself does not "exist". A paper based model that never knew of modern IT.
But it does not have to be like this, we have IT now. Thingamy lets a singular data-object represent a singular real-object, then capture the what, who and when onto itself. Not "what" as defined by some GAAP, but rather the "what" as in reality - now moved to warehouse B, now painted blue.
Transactions and events can thus be gleaned from changes to relations and properties: A change of the relation "is owned by" is often what legally constitutes a sale or purchase, thus useful for a (P&L say) report. A change to the relation "is located in" is useful to produce inventory reports at any time and so forth without limits.
Most important result - one data-object only per real-object, simple as in reality. A reality-model.
So, let's do a simple calculation: Say you have 20 objects to handle, 20 real world things and for simplicity, each goes through ten transactions or events (each event an object in legacy systems). Then relate them all, objects and transactions/events criss-crossing the organisational fabric.
Now to complexity - one way to measure is by number of objects times number of relations.
Thus the "complexity number" for the two modelling methods pans out to be:
Reality (Thingamy) model: 380 relations* x 20 objects = 7,600.
Transaction / event based (legacy) model: 48,180 relations x 220 objects = 10,599,600.
An increase in complexity over real-world complexity of 139,368%. Or about 1,395 times more complex.
Now do a more normal 1000 objects each represented by 10 documented transactions and you'll have more than 1.3 million times the complexity. That's how to complicate things in an efficient manner!
*Number of relations = [n!/k!(n-k)!] where k=2 and where relations are not symmetrical thus total is twice the number.
4. Make your competitors irrelevant.
If you want to kill Goliath do not let Goliath choose the weapons.
Neither let Goliath choose the battlefield. Let his immense defensive structures in peace and walk around, he will not know what hit him.
Hence do not fight best practices with more best practices.
Hence do not fight legacy systems with more legacy systems, make the legacy systems irrelevant.
With Thingamy and it's 1/1000th of the complexity and the ability to run all processes with same ease you have the slingshot with burning balls of fire at your disposal.
Rest of the useful stuff is icing on the cake.
(Read between the lines... this applies to both a user as well as any potential "partner
" of Thingamy...)
5. Build bespoke business models so you actually can have a strategy.
Thingamy is a business modelling tool, like a spreadsheet, so you have the freedom to create your own business model. Either from scratch or by tweaking and adding to one of the ready-to-use "solutions".
And this is how it should be - a strategy is defined as "What value are you going to deliver to what customer, and how are you going to be different?"
In other words; no bespoke business model, no difference and hence no strategy.
All promises about "best practices" is fine for some of the menial tasks, licking stamps say, but not for your business as such.
To build, or change a ready-to-use "solution" is easy, start out by revisiting your strategy. With the answer to "what value are you to deliver" you have the first piece of the datamodel, the main "object" to represent that real life thing you'd like to add value to.
Example for a hospital: Cure medical conditions could be the value add leading to the main object - "Medical condition".
Then you decide what other objects you need to add value to the main object. Again for the hospital a patient makes sense, as does x-ray, medication and surgery.
Last step of your data model would be how these relate to each other - "patient", "had", "medical condition" - and so forth. This adds "knowledge" just like Plato defined it - "how objects relates to other objects".
Then you can define the flows that the main object shall go through in order to create value with the help of the other objects (including the people who does the tasks of course). Make one big flow or create a library of flows that can be linked to each other, make loops and forks and whatnot and leave the rest to the participants.
Final step is to define report templates by defining real times queries, ordering and what to display.
And voilà you have a complete framework for all you do.
To build a smallish service firm from scratch would take a morning. Reckon 1/20th of the time a BPM system takes to create (without accounting and other reports).
6. Built for change, just like life itself.
See 3. above for how it's built or tweaked - obviously making changes is as easy, or even easier.
Make any changes even while the system is live, or run a parallel version for some fun testing and pilots until you get it right.
Change the sequence of a workflow, change the assignee, add a fork or loop or add properties to an class/object in minutes. Add IFRS to US GAAP for parallel reporting from same data in a morning and see all former years under both rules.
Start in a corner, run some small process and build from there when ready. Waterfall and up front analytics becomes a thing of the past. Just do it.
7. Report depth and true transparency.
Change is good, but you have to know when to change, what to change and in what direction a change should go.
And it should happen every day, just like an athlete trains with his goal in mind, testing himself, getting to know his "machinery" better for every stroke, step or pitch.
Hence the need for a best possible data model, best possible data and true history so that any regulation and requirement is fulfilled up front by the data architecture.
Thanks to the use of Semantic Web methods Thingamy can give you, if you fancy it, a report of "widgets sales in December to customers who has an uncle living in Berlin who cycles on Sundays and drinks Beck's beer". Or, thanks to true history, can give you "balance sheet changes for the period when I was out for lunch today". Translate ten years of US GAAP into IFRS in half a day and run both in parallel afterwards.
And never forget: A report is simply logic applied to raw data. Apply logic only when needed and keep all data in raw form. That will do away with applications, middleware, complexity and deliver far better reports. That's what Thingamy does - realising that presentation and representation are two different things. When we only had pen and paper those two were merged into scrolls, documents and forms - today we have IT and that concept is suddenly illogical.
8. Single inexpensive system to replace all in one go.
Thingamy is all in one - engine, DBMS, webserver and layout - copy to any OS, start and run.
It has all the "right" technology: TCP/IP communication, single or multitenant, XML-RPC based API, batch import / export of data and business model, extremely small footprint and extremely low resource use.
The cognitive dissonance starts with the claim that it can replace any and all other enterprise software - and email, meetings and more as well. All in one go.
Thingamy is process based disregarding the old notion of silos and separate processes. All activities in any business or organisation are linked to all others (unless it's chit-chat about last weekend's golf round) - Thingamy models all according to the purpose of the organisation and delivers a working process flow delivering tasks and capturing all that happens from A to Z. The captured raw data is then used by report templates to deliver all that is needed from lists to accounting reports.
9. Innovate by challenging all assumptions.
If you want to disrupt and innovate, tweaking an existing solution will never be enough. Speeding up trains did not much, inventing the aeroplane did. That's why Thingamy starts with some utter radical assumption challenges and takes it from there.
Here's a partial list, not purported to be entirely right, you might even disagree completely but that does not matter, it's still useful as an innovation tool. And keep in mind that the inertia of reality does not allow changes to happen in one go. Thus Thingamy is built so it can mimic the current situation for all aspects leaving the door to change wide open for those who wants to walk through it:
- The Organisational Hierarchy is kaput - as single purpose executor of the Business Model it requires reorganisation every time you need to get better, an utterly futile exercise most of the time. Replace it.
- Managing is a waste of time. Leadership I need, getting out of bed in the morning I can do myself.
- Legacy software models the "way we always did things" - usually a model from the days of paper, quills and desks. Model reality instead.
- Tree-structures are faulty. "Where it resides" is only two dimensional and suitable only for places. Use tags and any other means to enhance the knowledge and make finding easier.
- A report is simply logic applied to raw data. Apply when needed and keep all data in raw form. That will do away with applications, middleware, complexity and deliver far better reports.
- Double-entry book keeping (and thus modern accounting) was “invented” in 1494, based on paper and quills. Dump it and let the IT system that delivers the flows capture the real data and display it any way you want real-time.
- Budgets are completely silly. You know nothing about the future so forget it and leave such to soothsayers and magicians. Replace it with live benchmarking for example (like Statoil Hydro, Nestle and more).
- Think of processes as "what happens to things", not "what things happen".
- Documents and forms are bad - they only document "what things happen" creating reconciliation, errors and rigid processes. Let the thing itself capture what happens to it.
- Process is not a track, it's a football game where you see the goal and look for and try openings all the time. The ball is the flow.
- Flow is everything - flow is relationship, flow is knowledge, flow is context and flow creates value. Your business is all about flows, never forget it. Build the flows, then better the flows to better the value and your margins. Do it, then do it again, then do it more. Think extreme Business Planning.
If you want to dominate your business or fix your national budget deficit, please feel free to contact me.
Phone: +33 6 8887 9944, Skype: sigurd.rinde, Twitter: @sig, Email: firstname.lastname@example.org.
[Cartoon credits: Hugh MacLeod]