Implementation.
No waterfall implementation, start anywhere.
It does not matter if the first process is short or long, small or big - eventually all processes within an organisation are connected.
Start with something simple that is currently supported by email and meetings, then add more processes over time. That translates to low risk and an easy learning curve.
Thingamy runs on any server and clients are any browsers.
Other software.
While Thingamy does not need any other software it can connect to any through the open API.
It also have a simple .cvs or XML import mechanism and will have export abilities including SQL dump of all data.
Server / Client / SaaS.
Thingamy runs on any operating system (currently in beta only on Windows and OS X). Client is any browser but currently only supporting Safari / Webkit (that we prefer as they give us resizable text areas and inline views of PDFs) and Firefox.
Technically we can deliver Thingamy as a service but have no immediate plans, or any third party could deliver it as a service as a part of a value adding package. These are mainly yet to be set commercial issues.
BRP vs. ERP.
Easily Repeatable Processes (ERP) are typical linear processes with little or no conditional changes to the flow path. Barely Repeatable Processes (BRP) may have any number of changes to the flow path at all tasks - like a physician looking at an X-ray deciding what next.
ERP is a subset of BRP - and Thingamy handles BRP nicely covering processes that are core for consultants of any kind, government, health, education and any office or service that is project oriented - replacing email, Monday morning meetings and possibly some non-task-delivery support or management systems.
Data, SOX, Basel II etc..
Thingamy only stores raw data. Reports are generated real-time using templates and are not stored (beyond caching for speed).
Everything is captured historically by the objects themselves (the system being object-driven) allowing for historical reporting down to the second.
Balance sheet last Friday at 13:45:26 is thus possible, as are Balance sheet changes over lunch.
No changes to objects can be undertaken outside of a defined flow by a logged in user, any deletes in the process or data model itself merely disappears from sight but not from system allowing an architectural solution to full compliance to SOX, Basel II, Health regulation and other government rules.
Reports.
All data from the actual workflow is captured. Any change to the object properties and relations between objects as well as the process specific who, what and when.
With the historical data on hand any report can be produced at the "back end" with the user defined templates. The templates uses queries over relations and properties in any combination.
Any report can be sorted at report time by any property as well as changed historically to any point-of-time or time-period (where such makes sense).
Objects and relations.
Model object classes from real world objects, singular and minimal. Relate all objects as in the real world using W3C RDF N-triples to allow for any kind of query in multiple levels far beyond usual reporting capabilities.
"Sales of widgets in December to customers that have an uncle living in Berlin and that cycles on Sundays and drinks Beck's beer" is now possible.
No transactions.
Transactions can be mapped using queries over changes to relations. Widgets that changed the relationship "owned by" from the company to somebody else in December could be a GAAP definition of sales in December.
This allows for multiple GAAPs to run in parallel, translation of many years of accounting reports in a days work and any "my special cash-flow" report.
More importantly, the non-transactional architecture lowers the complexity with a factor of 100 or more from current systems. The result being flexibility, speed and data-amount-lowering allowing for running of processes no other system can and unheard of report depth.
User settings and rights.
Rights down to individual report visibility, flow transparency and ability to start a flow can be set in flows or ad-hoc in a management interface. Task templates in flows requires setting of what properties, objects and reports shall be delivered/viewable to the chosen user.
This ensures the right information and nothing more to each individual user or group of users.
