What can thingamy replace?
What's the biggest drawback for thingamy? (#1)
What's the biggest drawback for thingamy? (#2)
Can it reflect the current organisation?
How do you prevent accounts from seeing HR records and vice versa?
How is security taken care of?
Can the system use data and vice versa from other systems? Can it live with other systems?
What happens with all my other data that I have in my current “flow” if I move all to the thingamy?
Can I integrate this new thinking into old processes or is it a clean sheet (scary)?
Will my techies love/loath it?
Will my CEO find it too disruptive/risky?
Who will help me design this process?
Can I do it graphically as that (current) simple interface scares me?
What about automation of tasks and processes? Any intelligence in there?

What can thingamy replace?
CRM, ERP, accounting systems, supply chain management systems, business process management systems, all middleware, separate database, even wordprocessors, in-house e-mails, business model building tool, process testing tool, budgeting tool - and more, much more.

What's the biggest drawback for thingamy? (#1)
Users have a tendency to 'play' with the system. Like building your own budget in a spreadsheet, you get an idea how you could make it better the next morning. And the morning after...
But, of course, this is no drawback, it is a strength - as long as it does not keep the user from using the system for daily operations!

What's the biggest drawback for thingamy? (#2)
Certain migrated data from old systems may have limited use (unless de-scrambled): Accounting data are usually kept in a 'manipulated' form, as in P&L etc. where logic has been applied to the raw data. Thingamy uses the raw data on-the-fly to produce reports by applying logic, but never saves the manipulated data. For thingamy to use old data it needs the raw data. That said, certain work-arounds are possible, and old 'manipulated' data can always be stored and displayed.
It is nevertheless a less-than-dramatic impact, the issue simply restricts some former data to what it was. I.e. the depth of thingamy reporting would be missing for some pre-thingamy data sets.

Can it reflect the current organisation?
Yes, any form or function. Even more, it can use more than the usual two (classic hierarchy) or three dimensional structuring (grids) - it has no dimensional limits. Actually it can apply the same unlimited structure to more than employees - to any resource, and even that definition is limitless.
That said, you can start with your present structure and let you move slowly or fast into a hierarchy-less structure, a flat organisation when and if need be.

How do you prevent accounts from seeing HR records and vice versa?
Every interface, for each function or individual, is designed from bottom up - one have to choose what data the individual is allowed to see, ditto for what reports - information not deliberately 'ticked off' will never be available in any way to that individual or function. This can be done as 'rules' for 'groups' as well.

How is security taken care of?
Not limited to, but the architecture is the most important:
1. Data and Logic is kept in one server. That server can be mirrored to one or more remote and all can be interchangeable in case of physical disruption. (A house with no windows, only one door - simpler to control and safeguard.)
2. That server could run any of the standard server operating systems - choose the one that you're at ease and have best control over.
3. All interface with Database is per specific interfaces covered by passwords, user-names, cookies, Https, and so forth.
4. All information is in raw form and unstructured - thingamy is required to make any use of it.

Can the system use data and vice versa from other systems? Can it live with other systems?
An interface, say built using PHP (or any other standard environment) can easily connect with thingamy, and with any other database. The kernel is open to webservices and XML-RPC and can thus interact using open standards.

What happens with all my other data that I have in my current “flow” if I move all to the thingamy?
Port'em. It's pretty straightforward script business with a manual twist as when you flip PDA address-book to Outlook and so forth. Only problem - as in not possible, or useful - is to port manipulated data: A P&L we can keep as a proper document, or de-manipulate (more scripting). Remember that our system produces a report on the fly and never keeps the manipulated data - that way you can have a US GAAP, UK GAAP, YOUR-OWN-SPECIAL GAAP accounting report using the same data at any time! Including all former years...

Can I integrate this new thinking into old processes or is it a clean sheet (scary)?
Start out by simply copying old hierarchy and processes. Then fire it up. Then start moving (if you want to) towards any new structure or business model or whatever!

Will my techies love/loath it?
Think they will love it as it gives them a new extremely powerful tool to run everything, develop freely and respond quickly to new ideas. They'll be in the drivers seat!

Will my CEO find it too disruptive/risky?
Yes, some. That said, I think we'll see two scenarios (speaking from limited experience so far):
1) Radical/confident top management and we're off.
2) Middle management who needs ways to structure iffy local processes or have other local needs. Once implemented for a local process the system may very well migrate naturally from there, as in the question "what then after that process?" or "what leads up to that process?" - both with a simple answer "why not add some on the tail, and at the head?"
This last one is the one we see in the big companies. The first in smaller ones - up to 1000 employees so far.

Who will help me design this process?
It can be done in-house with some educational-start-up support, and/or by a business oriented consultant / SI. That said - it can open up for new products/revenue streams for business oriented consultants with a bare minimum in technology understanding!

Can I do it graphically as that (current) simple interface scares me?
Sure. Just have to build the interfaces first! I.e. it is a question about what programming language the interfaces are built in. Would need more Java type stuff as pure html as of today have very little. But the kernel is completely ready for it - XML-RPC interface is there already.
P.s. Interfaces - the stuff that makes it look like something, as well as for usability and 'applications' (=logic applied = reports in our lingo) can be another products opening for consultants or the SI's.

What about automation of tasks and processes? Any intelligence in there?
Any task/event can be followed by a rules set / constraints applied automatic task. If this or that, then go there. This generic approach will enable most logic constraints for the workflow and automate many 'dumb' issues.