What is enterprise software?

The short answer is; “a process standardising database and interface for all organised communication needs”.

Given that busyness is often the antonym of business, as entrepreneurs, our quest for business to exceed busyness is the process of building a framework that generates the good kind of business, and minimises the costly kind of busyness that people may naturally feel is better than doing nothing, without a direct connection to the organisation and reports through these standardised data-processing systems.

Time is a finite resource but infinite place for value to be lost through – that is, without an organisational structure designed to capture and utilise knowledge, and offer that to the world as greater value from what we produce and create, over and above what we need to consume to do so.

For a very long time, I refused to write a *requirements document* for developers, simply saying something along the lines of; “look at every website you use and enjoy, then make sure we can do all the same and more, faster, better, cleaner and simpler” – and personally understanding that I saw as the qualifying level of awareness necessary to able to do this.

Now, with the greatest of respect and admiration to all the many great platforms and missions out there, and our esteemed and perseverant team, I find a decreasing number of examples that I don’t think we aren’t either surpassing or able to surpass eventually with the Brandlight platform we have started, meaning we just couldn’t find the examples that covered everything we knew was needed for inspiration.

So here we are now with our Brandlight platform, and this open wish-list in the public domain for your use, interrogation, comparison, and publicly accountable message to our whole team, your various stakeholders reliant on your research, and your good self for taking the much-appreciated time to read into the details.

Asynchronous communications

In my humble experience, any organisation that works with people in more than one place and time can be classified as an enterprise – because the information now has to travel between people over time, and be accessible by anyone that needs it at different times to those that created it might be available – and of course the same person with enough on their mind already for the same reason we keep address books and diaries.

We call this *asynchronous communications* – where the sending and receiving times differ.

Parallel communications

As a general rule, when a business is multi-location or has more than two or three staff, and is likely to want to grow, then it can have almost as many of the same needs as organisations with hundreds or thousands of members.

We call this *parallel communications* – enabling scaling via multiple simultaneous independent messages.

Serial communications

Teams above around five or six will find it difficult to know what everyone is doing all the time, and generally we tend to work best in pairs with equal and opposite skills – so for software to be enterprising, it needs to work with the way we work best, and generally that is by becoming a fast and simple answer-machine without becoming *work* overhead or latency in itself.

We call this *serial communications* – where efficiency is solely dependent on speed and accuracy.

Consensus-based decision making

Typically this will be a database and search-engine for our collective organisational knowledge – it’s databases exist to solve – and to be accessible to everyone in and working with the organisation. For which we look to the most commonly available and universal application interface on all devices, the web browser.

We call this *consensus-based decision making* – whereby we seek confirmation through verbose articulation, common-denomination, error-correction and objection-free agreement.

Proof of concept market research

With all the ambition in the world, make sure you do your market research for a proof of concept, something AI can now help with. The biggest financial risk you have is in developing something that doesn’t have enough demand.

What should you look for in enterprise software?

You can use this as a high-level requirements document for briefing and developing your own IT systems software suite, and reviewing our Brandlight platform development considerations and experiences in comparison.

Security

You should definitely know who has logged-in, when, and what they did through an access log that identifies the user, IP address, device, platform and browser.

Social logins are abundant, personally protected and have well-understood credentials protection and management systems nowadays, so that’s a great starting point for accessing your systems.

Then all users with access to valuable privileged information and financial or inventory movement actions should have two-factor-authentication protections on their user logins too, for additional protection of those valuable access credentials linked to the devices that the user is generally the sole custodian of, their computer login or their smartphone.

All code changes on the system should be visible by all qualified developers also working on the systems, for peer-to-peer review and security through visibility of the complex capabilities that developers can create.

Data protection

Personal data should be encrypted for the ultimate protection from their being any value in any hacking attempts because you cannot steal what does not exist – and decryption access keys should be issues and limited based on user-signed logins and role-based permissions.

All personal data transfers should be encrypted or limited to the minimum essential information necessary for validation confirmations, for example just the last 4-digits of a card number.

Customer identification should use information that only they could know, that you can also see, like order history or common transactions – not publicly easy to find information like birthdays and post codes.

All users with sensitive access levels should be identified and have personal identification documentation stored for traceability and accountability.

It should be impracticable for any single user to export batches of unencrypted data.

Developer’s don’t need access keys to view encrypted data because the users that do can always access their systems through two-factor authentication or linked-account authentication such as email or social logins.

No single person should be a single point of failure or data-loss, ideally there should always be multiple audited key-holders in multiple locations – and just like the Royal Family, never all in the same place at the same time.

Data, content and media sharing

It can be very frustrating for people to need to ask another person for data they would prefer to be able to see directly, without the latency of messages and waiting times to get it in the form they are hoping for.

We can share food, but we can also make virtual shopping baskets – so it also nice to apply those same skills in providing for requests and responses with these same tools.

So, everyone that needs content, analysis reports or KPI data should be able to access that through their login and search facilities by self-service – therefore saving everyone’s precious time to focus on the review, reuse and response all available data.

This goes for teams, departments, customers and the many, many partner-types we will engage in over the course of our various projects. It is usually the partners that can scale our network of knowledge and promotion the fastest too, so the quicker we can empower them with data and the answers they contain, the quicker we can all develop.

Hidden or restricted data that is already protected by confidentiality or other types of agreements should be made readily available – so we can all learn and evolve together at a speed and level of reliability that adds value to our collective offerings to the world.

Audit-trail activity data

Long gone are the days when managers could shoulder-browse what computer users are doing or read everyone’s communications – nowadays, the best method of information and resource security is keeping audit-trail data on all computer activity to be searched, filtered, reported on and reviewed in the event of any investigation or performance measurement and optimisation needs.

Accountability

Every single data change should have a name and timestamp attached to it – people look after the things they have their names on – ideally also with their public security key-stamp and a hash of the content to reconcile it’s version at that point in time of creation or updating.

There can be a self-preservation tendency for people to feel that the value they offer is in the information they have in their brains – but actually, the most valuable team-members continually create and share knowledge to leverage what they are learning for their colleagues to learn and utilise faster too.

The most valuable team members are generally also the most verbose, whether through communications or activity-logs, because there’s simply less overhead in understanding what they do, and more information to work with to help them optimise the use of their time with all the resources they need.

Whereas, guarding or withholding information, methodology and actions generally has the opposite effect in making them seem redundant, or a potential obstacle to others building upon that information for the greater good of many more people.

Named attribution for creative credit

One of the best best ways to sharpen attention to quality of output is through public publishing, and motivation that comes from recognition, credit, comments and feedback. Everyone should have the ability to publish their expertise within an organisation for all of the personal benefits and the human connection that organisations are merely a collection of people working with common aims and aspirations.

The same applies to private publications for the various permission-based roles too – it’s nice to know the people you work with and, who knows what, and also who viewed and contributed to the creative process.

Financial, inventory and resource transaction journalling

Cash, credit, account balances, inventory and time are all costs to an organisation, and how they are used and moved always has an opportunity-cost value in their efficient deployment – that ultimately results in the overall performance of the organisation and satisfaction of the team working in it.

Every single movement must be recorded, for then reporting on who, when, why and how – so that we can understand what is a positive use of finite resources, and what could be better. Without this data, we are blinded to the necessary information to make opportunity-cost decisions and directions in the mutual pursuit of efficiency, accountability and transparency.

The number-one complaint we see again and again, is that people cannot get the information then want to then make their own decisions – journaled accounting records and reports solve this.

The future is definitely immutable public blockchain ledgers and private database ledgers of all records – as proof of data events, times and signed-participants.

It is only a matter of time before all platforms and applications will have this woven into every data-creation event, and likely it will become a regulatory requirement in every area too, as it already is with GDPR and HIPAA compliance – because there should never be any changed data, because all updates are new transactional versions of the original.

The technology exists now to do this and store it all, starting with the large volumes of transactions that any organisation engages in internally and externally every day – and we wholeheartedly promote this for transparency and confidence in every organisation offering value with their goods and services to their audience.

Management

The very definition of management is changing to be one of experienced mentors, structural system implementors, relationship builders and policy, process and terms designers.

Management needs systems designed to enable this to be effective, an outlet for publishing their knowledge and an interface for setting and updating system rules to match policies and terms of engagement, and they need to speak the common language used in all departments beyond their own through systems organised by design to be familiar and intuitive across all departments and areas of responsibility.

Role-based permissions

People tend to change more often that roles, and rightly so as they develop personally, acquiring more experience, confidence and responsibility.

Permissions should be based on roles, and then people can be assigned one or more roles, with cumulative permissions for each role they take on.

This is one of our defining requirements for all systems we work with, to be role-based, or at least group or project-based, to then make the user permissions management time-costs minimal, and marginal to benefit from economies of scale, in that as the number of users increases, the total user administration should decrease relatively.

The most common user-role that almost everyone will recognise is that of the Customer, then there can be that of a Vendor, Brand, Manager, Administrator etc. These roles, terms and information access permissions needs are generally universal across all organisations, so it is an area and opportunity for standardisation and therefore management and repetitive explanation cost-savings.

Self-documenting

The optimum place to document any system, is within the interface itself – right where any questions or uncertainties on first-use can occur. Often this will be in tool-tips, form field descriptions and meaningful warnings and validation error messages.

When a system is not an application interface, or spans multiple systems, then the main system for documentation should ideally be within the same user access permissions and tools that are most commonly used – which for the customer is often the website, and all users should also be considered customers of the website and systems too.

For many organisations, this can still be file-servers and word-processing applications, although the lack or commonly available and easily controllable templating creates a large overhead in first that templating, then duplication of data creation, and further in differences in organisational interpretation, terminology, naming conventions and hierarchical ideas.

Therefore, the main systems database for most published organisational data is usually the website, which then becomes a natural place to also contain all the private organisational documentation too – right where the data references can be created through a linked relational interface, and all users should be the best customers and feedback providers for the organisation’s web systems – because it has the most significant effect on their customer’s experience of them too.

Changing systems is often one of the least favourite or trusted things to ask of your users, so it is nice to know that the system you introduce them to can be the last system they will ever need to access and work with in building, partnering or providing their faith and custom with your organisation.

Minimise data and work duplication

The more systems you have, the more duplication of data you will have, as each system has minimum human-readable identification data requirements – therefore, the more inefficiencies you add through duplication of data-creation, updating and general multi-systems effort with every additional system.

Undesirable data and effort duplication is not to be mistaken for the highly desirable replication and iteration – for data for security and accountability.

Minimise unnecessary integrations

This is a controversial one in an age with separate apps for everything, and many people recommending the specialist for this or that in each area of concern, be-it accounting, customer support, documentation, project management, calendaring, reporting etc – but this is a re-invented wheel for a concept that already worked very well, typically knows as plugins.

Plugins work within the same application and database, and are therefore integrated by design. Specialist web-apps are nice, and can solve many things – but they also carry integration overheads that plugins don’t.

There is a smaller overhead in conflict resolution when using disparate plugins of varying quality, terminology or respect for platform standards – but those are generally more manageable when working with open-source systems, so plugins can be evolved, adapted or re-written into the core application.

Systems and teams that work with and develop plugins will generally already know how to do this – and will have made their enterprise platform choices based on all the knowledge contained herein anyway, so choosing a plugin-based system and team will generally also then mean choosing to minimise integration overheads, and maximise capabilities all within the same system.

You can de-duplicate data creation and updating with systems integrations – but there is an overhead in retaining the people that understand how to do that, and the systems that can.

There are inevitable necessary integrations to 3rd-party systems that you can never converge, so they should be the focus of all integration needs.

Save your finite resources from internal systems integrations by simply minimising the number of systems with data-duplication – this goes right down to the simple users table.

The less internal communications you have to manage the more time you have to focus on your valued and appreciated outward communications, products and services.

Standardised structure and language

Supplier, Manufacturer, Vendor and Brand and all very similar concepts, but with subtle differences, and an entity can be one or more of these – so it is best to have the scope to describe each and its functions and properties, and then attribute users and entities to all those partner-type concepts as roles.

Consistency in usage and language should be self-explanatory, by example, whereby new users can look at current data in determining how to create new data.

Generally, we are familiar with English as a parent language for code, development and systems, so we start with this, and that becomes the seed for all translations.

A precise and consistent use of language is critical for all successful communications – therefore extra attention to this should be a good measure of character and empathy of system designers for their users.

Data objects

There are many things common to almost all organisations, that have similar but unique properties but are related by common overall aim, to create and offer value.

You will probably recognise most of them anyway, we just make sure we are clear and distinct with their naming and relationships to make the knowledge gathering and sharing they enable intuitive:

About Us, Accounts, Achievements, Activities, Advertisers, Advocates, Affiliates, Agreements, Alerts, Alternatives, Ambassadors, Amounts, Analysis, Analytics, APIs, Applications, Approvals, Articles, Assignments, Attributes, Authorities, Authorisations, Banners, Baskets, Blocks, Blogs, Bookings, Brands, Campaigns, Canonicals, Carriers, Cases, Categories, Channels, Checks, Children, Creators, Comments, Commits, Companies, Competitions, Compliance Rules, Connections, Contacts, Contents, Conversations, Conversions, Costs, Coupons, Countries, Courses, Currencies, Customs, Data-Feeds, Deployments, Descriptions, Devices, Documents, Domains, Donators, Editors, Embeds, Entries, Events, Experiences, Exports, FAQs, Features, Feedbacks, Forums, Feeds, Fields, Forms, Galleries, Gifts, Groups, Guests, Help, Home Pages, Images, Imports, Indexes, Information Pages, Ingredients, Integrations, Investors, Invoices, Journals, Key Performance Indicators, Labels, Languages, Ledgers, Licences, Links, Lists, Logs, Loyalty, Manufacturers, Media, Memberships, Menus, Messages, Milestones, Monitors, Movements, Newsletters, Notes, Nutrients, Options, Orders, Organisations, Packaging, Packing Slips, Pages, Parents, Partners, Patents, Payments, Payment Details, Permissions, Points, Policies, Portfolios, Positions, Posts, Presentations, Priorities, Processes, Products, Projects, Purchases, Qualifications, Quotes, Rates, Receipts, Referrals, Regions, Regulators, Relationships, Reminders, Repeaters, Reports, Resellers, Restrictions, Revisions, Risk, Robots, Roles, Sales, Samples, Schedules, Sections, Services, Settings, Shipments, Sponsors, Statuses, Stores, Synchronisations, Tables, Tags, Tasks, Terms, Themes, Tickets, Tokens, Tools, Trademarks, Transactions, Transients, Translations, Types, Units of Measure, Users, Vacancies, Variations, Vendors, Versions, Visibility, Visits, Warehouses, Websites, Widgets, Wikis, Workflows, Worksheets, Zones.

It is a long list – but it is also finite, and therefore achievable – and still relatively understandable by most I hope, and insightful to others that may still be learning conventional terminology and its typical usage context.

Not everyone or every system will even try to achieve all of that – but often they will encounter all of those event types in their experiences – and, in most cases, can benefit from a way to store, publish or search and review the related records of information on them.

When you use the tools you create, you tend to use that continued experience to then evolve a time-efficient system and process for each repeat event or descriptive need, so here we are, and this is the broad but still describable complexity of organisational interactions from our longstanding experience.

I challenge you to find a system that doesn’t contain many of these common terms – and further still, to find another one that has all of them already thought-out and organised for you, based on these decades of organisation experiences, we couldn’t, hence we used the development and communications skills we have acquired to offer our description of an organisational framework.

Workflow

There are some concepts that should be standard for all records, just as there are recognised meta-data attributes on all digital files like Name, Created, Last Updated, Type, Location etc.

We have the following concepts for universal record workflow:

• Open > Yes or No
• To-Do > Multi-select Users
• Roles > Multi-select for Roles
• Assignee > Single-select User
• Priority > One of five simple options: 1. Low, 2. Normal, 3. High, 4. Urgent, 5. Blocker.
• Status > One of three simple options: 1. To-Do, 2. In Progress, 3. Done
• Type > Multi-select for (data-)Objects

Colour-coding

Performance and attention colour-coding using traffic-light colours;

• Red = Urgent, Warning or Error
• Yellow/Orange = Alert or Attention
• Green = Good or Done
• Blue = Neutral Information

Status colour-coding using rainbow-colours & neutrals: Black, White, Grey, Red, Orange, Yellow, Green, Blue, Indigo, Violet.

Document-flow

For financial documents this is quite simple and conventional:

1. Quote
2. Order
3. Proforma Invoice
4. Payment or Credit Voucher
5. Invoice
6. Shipment
7. Return Order
8. Credit Memo

For products this will be:

• Brand
• Title
• Description
• Imagery
• Attributes
• Pricing
• Labels
• Documentation
• Compliance Rules
• Reviews
• Related

Every single data record can be defined and described as a ticket or a to-do, so we apply the same universal workflow data-attributes to all records regardless of their object-type because they all go through the same creation processes at varying speeds, and invariably the better the organisation of data, the better the organisation.

Policies

Predictability is an essential element of successful planning, for which consistency is our friend, and the unexpected can often be our biggest time-cost.

With respect to offering value through efficiency, it become necessary to have a consensus among a team, and those that work with that team, on what their typical policies are – so that everyone working with them knows how to, and if they even can.

It’s better to ask permission than forgiveness, and policies are a great way to guide with preemptive permissions to save on repeating directions or managing varying undesirable or unnecessary interpretations.

If something is done in many different and undesirable ways, that’s good inspiration for writing a policy on what is most desired and expected, we can disagree with policies but we can’t deny knowing them when they are written and conditional to engagements.

Terms, Conditions and Agreements

Organisations are the collection of relationships, and the building of long-lasting relations starts with the shared understanding and agreement of expectations.

We are all finite and can’t be everywhere and do everything for everyone – let the world know what you can and will aim to do, and what is expected of them to work with you, including how renumeration is calculated, ie: your price, and what you will do, or can’t do, when some things occasionally don’t go as planned, whether for reasons within or outside of your control and accepted responsibility.

In contractual legal terms, your descriptions, prices and, terms & conditions agreements are your *invitation to trade*, usually via a checkout basket completion and proforma invoice. The act of purchasing is an *offer* to undertake a contractual request based upon those terms, which is *accepted* by the exchange of the agreed *consideration* but *both* parties, which can still include the passage of time for review of each other’s delivered consideration.

Get this right, and you can focus on the doing.

Skip the details here, and expect your counter-parties to have a tendency for seeking preferential advantage in the face of uncertainty or doubt when terms are not clear, reasonable and potentially perceived differently as to what is *fair*.

Make sure you create agreement terms for every relationship-type you are inviting customers, partners and team members to engage in, and in a time-friendly way to exchange and sign, to then focus on working within them.

Yes, documents, terms and wording are just as much systems as computer-programming-code – think of them as people-code – treat with with the same need for attention to detail – and expect your systems to have them woven into every contractual engagement to promote friction-free delivery and happy repeat business.

With the right enterprise platform choices your time should be freed from needing to write computer-code to develop platforms and systems – because your systems developer’s work is designed to liberate you to  then do the same diligent and sensitive creation for your relationships, products and services.

FAQs

This is your chance to eliminate objections, issues, concerns and show empathy for your potential relationships.

We all start an evaluation from the point of scepticism and risk-assessment – how likely are we to be disappointed or controlled beyond our expectations?

Tell people, we all get lots of questions on lots of things all the time – they are just opportunities to answer and reassure or guide the first person to ask as much as they are to pre-answer for all those that have not yet asked.

A lot of questions, is still not an infinite amount, and if it is finite it can reasonably be expected to be stored and represented.

This can be on products, services, compatibilities, terms, policies, enquiries or support tickets through canned but hopefully more personably written responses build up from FAQs.

Reviews

Public reviews are a modern phenomenon, pioneered by Ebay, and now an essential key performance indicator metric, and source of independent social confirmation for promoting the views of your customers, teams and partners in their own words.

As humans, we are still better at *reading between the lines* than computers, so we will be judged on these whether we agree or not – but we must secure the value of that feedback by providing a direct outlet for it – and using it as a primary guiding light for direction and evolution to remain relevant for future potential relationships.

The more you enable reviews on, the more valuable and often free feedback you gather to refine and evolve – feedback is the most valuable currency for developers after food, shelter and technology to create, so the more the merrier as far as we are concerned – so make sure your system asks for them and makes them possible in every place that can benefit from this continual enlightenment.

If you don’t like or understand something, tell us. If you love it, tell everyone!

Accessibility

This is possibly one of the most difficult hidden things we can do without personal experience but a responsibility we have to society and ourselves, never knowing our future fortune or functional lifespan expectancy for our fallible limbs and senses, especially when the vast majority of our occupation relies so much on our eyes and hands.

With this mind, it is something we do believe is important regardless of the percentage of users it may accept because we are all uniquely different, and it’s just nice and the right thing to to to try to be both understanding and use the privileged skills and technologies we are brief custodians of to do the best we can by everyone – and invite those that do have more direct personal experience to help us if they wish too.

Extendibility

We can’t know everything we might do or need all at once – so we start with everything that almost everyone needs, and learn through continuous feedback what new things we might want to do – and make sure there’s a place to then add those things, with both structured freedom from any artificial limitations like user-count, records, objects or functionality.

This doesn’t mean having infinite choices on how and where to do something or find infinite ways of saying or doing the same things – but to have infinite places to extend and build upon what we can already do that is *almost* the same, except for that one new thing, so that new thing has an obvious and local place to be added without barriers or disproportionate costs.

In database design terms this generally mean new users, customers, partners, messages, records, options, terms and fields – all of which should have an obvious place to be added when inevitable unique needs arise.

Scaleability

What happens if your sales or messages double or more? Your audience and attention suddenly rises temporarily or permanently?

Yup, your enterprise software platform should have already though of that, designed accommodation for it and put in place flood-gates, surge-outlets and safety-fuses for reasonable costs and agreed resource limits.

You might need to know how but you can reasonably expect to see test-data on peak performance load-testing.

Multi-dimensional

This needs to be part of the system design from the beginning because it can be either very difficult, or potentially impossible to add later when you do need, but you should be looking for the following to be already considered by design:

• Multi-currency – to open yourself up to the inevitably larger exports markets when your products and services find an audience beyond your home country.
• Multi-lingual – search engines and customers can often prefer local language offerings where available.
• Multi-channel – to be where the many different types of customers are, and offer what they are hoping to find there.
• Multi-media – information comes in all shapes, sizes, formats and places.
• Multi-location – stores, warehouses, countries all need their unique properties described and their different processes catered for.
• Multi-role – because not everyone can do everything, so we need to build a team with specific responsibilities to divide & conquer the growing requests for our products and services.
• Multi-tier – for small and large customers ordering occasionally or regularly.
• Multi-rule – we live in a world of rules, generally with good intentions, we need to articulate and respect them.
• Multi-partner – every user is also a customer.
• Multi-device – big-screens, little-screens, portable-screens – landscape and portrait

Time and location replication

Your data should be stored in multiple locations for what we call *geo-redundancy* protection from the typically physical events like fire, flood and theft – and nowadays potential internal or external unauthorised access and copying.

It should also be stored in time too – because we are all still human and, with the best of intentions, still make various mistakes along our learning curves – for which we should always have access to previous versions to look back and recover any point in time before any erroneous actions to protect ourselves from good human ourselves too but using the computers to give us almost infinite memory, hindsight and recovery methods.

Data-ownership

Customers must own their own data, not everyone respects this but it is now a common regulator requirement that must be respected as much as your customer’s personal privacy, legal and moral rights through transparency and systemised access and control to that privileged information they share in good faith.

Organisations must also own their own data to own the value from the knowledge it contains.

No vendor lock-in

The key to this is in these very specific things:

• Standardised and recognisable data-structures and storage protocols.
• Ownership of storage accounts.
• Open-source code

Open-source code

This doesn’t necessarily mean publicly available code – but it does mean privately interrogate-able by peer-review, feedback, recommendation and potentially contribution.

Most enterprise platforms don’t offer all these things, although enough do and it is worth considering as you choose to place your knowledge value in either their custody for closed-source proprietary vendors, and hope they remain pleasing and affordable, or shared-custody with open-source vendors that you can dismiss and change within the terms of your notice period and retain control of the storage, data and code with which to gather and present it.

Ideally you want visibility of development commit change-logs, for visibility on systems evolution – most licensed software has always offer this with their updates – but often SaaS or PaaS web-app services nowadays don’t give the same level of detail as they iterate, which is unnecessarily opaque when those changes are usually very visible among their team and could help with expectations for when something might be changed, fixed or added because the unexpected surprises are contrary to the planning needs of establishing or growing an organisation.

Can enterprise software ever be finished?

Yes – absolutely – when all of the above is in-place and working 99.9% of the time, perhaps even 100% soon – if the structure can be understood, and organisations – as the most common and long-running human structures we know – and requirements can be articulated, here-in – then there is no reason why the software cannot be finished any more than a video-game, other than from learning the rules and needs, then applying skill, time and dedication to finish what we start.

Value is the sum of all knowledge

All the value in the work we do is in the knowledge and deliveries we create – everything else is an overhead and a cost – and efficiency comes from doing more, faster, with less – hence our quest to use the platforms that already exist and are tried & tested, in ways that put all this capability within a single login.

You can try doing this with many separate applications and integrations and duplications – we’ve tried that too – but in this particular area, less is certainly more – especially when you are your own biggest client and can combine the value of learning needs through usage, and gather the development capability to describe all organisational events in a data-structure and information flow.

If you can store knowledge and share, you can accumulate value – just as is reflected in the relative value of national currencies and corporations shares, for the knowledge, resources, and entrepreneurial spirit they contain.

These are all finite requirements, achievable and actually already done today by many, many software applications – we’re just replacing the many competing, disconnected and incompatible systems with one open-source platform that can offer all this to everyone that works with us to store and share their knowledge and value efficiently.

Can software systems replace people?

It’s amazing that it takes all this complex systems development to achieve the same bandwidth a two enlightened humans in the same place, at the same time – but this is how we work together, as one, across time and space with perfect memory – and how it is increasingly possible for people to work with each other anywhere they have an internet connection, to be more capable than any one of us.

Freedom from repetitive, mechanical and robotic work frees our finite time and energy for inventing, creating and relationship-building – through the gathered intelligence our complimentary systems bring with us.

So no, software systems can’t replace people or make them redundant – they can make repeat *work* tasks redundant though, which in-turn *increases* our value as creators and connectors to share our value propositions, and be rewarded for delivery of our shared vision.